La digitalización de los procesos y servicios comerciales conlleva enormes ahorros y una mayor eficiencia. Para ser sostenible, este desarrollo no debe introducir serias vulnerabilidades de seguridad, pero desafortunadamente a menudo lo hace.
La superficie de exposición a delincuentes y otros actores maliciosos aumenta cuando los procesos comerciales migran total o parcialmente a plataformas en línea. Esta exposición global a las amenazas de seguridad hace que sea natural usar el término ciberseguridad en el sentido de proteger los activos que están conectados directa o indirectamente a Internet.
La seguridad cibernética sólida en todos los niveles es necesaria para mantener un perfil de riesgo equilibrado en una economía digital.
Lograr una infraestructura segura de TIC obviamente requiere que esté diseñada, construida y operada por personas que entiendan las amenazas, conozcan los requisitos de seguridad y tengan las habilidades para construir y operar sistemas seguros en general.
Este documento analiza cómo se puede fortalecer la ciberseguridad, no invirtiendo en herramientas de detección de ataques y filtrado de malware más sofisticadas, sino garantizando que los cimientos de la infraestructura de las TIC estén diseñados y construidos para una seguridad y robustez sólidas.
Esto solo se puede lograr asegurando que el diseño seguro del sistema se convierta en un elemento natural en todos los proyectos de desarrollo. Y alentando, estimulando y quizás obligando a los colegios técnicos y universidades a integrar módulos de seguridad obligatorios en el plan de estudios de sus programas de educación de TI.
Indice
¿Qué es el desarrollo seguro?
El desarrollo seguro de software y aplicaciones supone tener en cuenta la seguridad desde el inicio del ciclo de vida de los mismos.
Las vulnerabilidades de seguridad en el software generalmente son causadas por programadores o equipos con habilidades inadecuadas en el desarrollo de software seguro.
Desafortunadamente, miles de diseñadores y expertos de TI en todo el mundo carecen de habilidades de seguridad precisamente porque la ciberseguridad no era parte del programa de estudio que siguieron en la universidad. La infraestructura de TIC en expansión en todo el mundo está siendo construida por expertos en TI con títulos de universidades y colegios. Y muchos tienen una comprensión y experiencia de seguridad insuficientes. Esta es una situación inaceptable.
Por ejemplo, sería irresponsable e impensable educar a arquitectos e ingenieros civiles sin darles el conocimiento adecuado sobre seguridad contra incendios. Así, los edificios en los que trabajamos y vivimos estarían llenos de trampas de incendios.
Asimismo, es irresponsable ofrecer programas informáticos en universidades sin módulos obligatorios en seguridad de la información. Desafortunadamente, aún hoy muchos graduados de TI abandonan la universidad y entran a la industria sin ninguna competencia en seguridad de la información.
A pesar de sus grandes habilidades en programación y diseño de TI, sin habilidades en seguridad, estos graduados de TI necesariamente construirán soluciones de TI vulnerables.
La implementación de un ciclo de vida de desarrollo de software seguro (SDLC) es importante ahora más que nunca.
Ciclo de vida de desarrollo de software, ¿qué es?
Un ciclo de vida de desarrollo de software (SDLC) es un marco que define el proceso utilizado por las organizaciones para crear una aplicación desde su inicio hasta su desmantelamiento. A lo largo de los años, se han propuesto múltiples modelos estándar de SDLC (Cascada, Iterativo, Ágil, etc.) y se han utilizado de varias maneras para adaptarse a las circunstancias individuales.
Sin embargo, en general, los SDLC incluyen las siguientes fases:
- Planificación y requisitos
- Arquitectura y Diseño
- Prueba de planificación
- Codificación
- Pruebas y resultados
- Lanzamiento y mantenimiento
Una práctica habitual en el pasado era efectuar actividades vinculadas con la seguridad únicamente como parte de las pruebas. Esta técnica posterior al hecho usualmente resultó en una gran cantidad de problemas descubiertos demasiado tarde. Sería mejor incluir actuaciones en el SDLC para ayudar a localizar y reducir vulnerabilidades antes de que se produzcan, introduciendo la seguridad de forma efectiva.
Es en este espíritu que surge el concepto de Secure SDLC.
Un proceso SDLC seguro garantiza que las actividades de garantía de seguridad, como las pruebas de penetración , la revisión de código y el análisis de arquitectura, sean parte integral del esfuerzo de desarrollo.
Las principales ventajas de seguir un enfoque de SDLC seguro son:
- Un software más seguro como seguridad es una preocupación continua
- Conciencia de las consideraciones de seguridad por parte de los interesados
- Detección temprana de fallos en el sistema
- Reducción de costes como resultado de la detección temprana y la resolución de problemas
- Reducción general de los riesgos empresariales intrínsecos para la organización.
¿Cómo funciona?
En términos generales, se configura un SDLC seguro al agregar actividades relacionadas con la seguridad a un proceso de desarrollo existente. Por ejemplo, escribir requisitos de seguridad junto con la recopilación de requisitos funcionales. O realizar un análisis de riesgos de arquitectura durante la fase de diseño del SDLC.
Se han propuesto muchos modelos de SDLC seguro. Éstos son algunos de ellos:
- MS Security Development Lifecycle (MS SDL): uno de los primeros de su tipo, Microsoft SDL fue propuesto por Microsoft en asociación con las fases de un SDLC clásico.
- NIST 800-64: proporciona consideraciones de seguridad dentro del SDLC. Los estándares fueron desarrollados por el Instituto Nacional de Estándares y Tecnología para ser observados por las agencias federales de los Estados Unidos.
- OWASP CLASP (Proceso de seguridad de aplicaciones completo y liviano): simple de implementar y basado en MS SDL. También asigna las actividades de seguridad a roles en una organización.
¿Cómo empiezo?
Si eres un desarrollador o probador, hay algunas acciones que puedes adoptar en tus actividades diarias para mejorar la postura de seguridad de la organización, que incluyen:
- Infórmate tú y a tus compañeros de trabajo sobre las mejores prácticas de codificación segura y los marcos disponibles para la seguridad.
- Considera la seguridad al construir / planificar casos de prueba.
- Uss herramientas de escaneo de código como SecureAssist, Coverity y AppScan Source .
Sin embargo, la gerencia debe estar involucrada en el diseño de un enfoque estratégico para un impacto más significativo. Como tomador de decisiones interesado en implementar un SSDLC completo desde cero, aquí te mostramos cómo comenzar:
- Realiza un análisis de brechas para determinar qué actividades y políticas existen actualmente en la organización y su efectividad.
- Configura una Iniciativa de seguridad de software (SSI) estableciendo objetivos realistas y alcanzables con métricas definidas para el éxito. Los procesos para las actividades de seguridad deben formalizarse durante la configuración de SSI.
- Invierte en la contratación y capacitación de empleados, así como en las herramientas adecuadas.
- Usa ayuda externa según sea necesario.
Patrones de ciberseguridad
Actualmente hay en el mercado una gran cantidad de herramientas y servicios para fortalecer la ciberseguridad. Los proveedores van desde compañías grandes y de alto perfil hasta compañías pequeñas y relativamente desconocidas.
Se promocionan algunos productos de seguridad para detener las APT (amenazas persistentes avanzadas). Se promocionan otros productos para detectar y detener ataques singulares de día cero o para filtrar malware.
La detección y prevención de intrusiones se puede comprar como un sistema o como un servicio. Marcos de gobernanza de seguridad como COBIT, ITIL o ISO 27001 pueden ser adoptados y aplicados por el personal interno de gestión de seguridad o por consultores externos para garantizar que la organización se gestione de acuerdo con las mejores prácticas en materia de seguridad. Sin embargo, ninguna de estas herramientas, servicios y marcos, ni de forma aislada ni en combinación, son suficientes para evitar serias vulnerabilidades cibernéticas.
Parece que no existe un enfoque que pueda proporcionar el nivel de garantía de seguridad al que apuntan los gobiernos y empresas. No hay un único proveedor, ni siquiera un conjunto de proveedores importantes, que domine el mercado de la seguridad cibernética y desde el cual se puedan comprar soluciones generales de seguridad cibernética.
Depende del CISO (Director de Seguridad de la Información) o un ejecutivo similar en las empresas crear y ejecutar el programa de ciberseguridad como que consideren apropiado, pero esta tarea es complicada al no existir un servicio, producto o programa comúnmente aprobado que pueda ofrecer ciberseguridad completa. Incluso cuando se siguen las mejores prácticas de la industria, habrá vulnerabilidades que los atacantes pueden explotar para montar ataques exitosos. En esta situación, es cuando ocurre un incidente de seguridad grave, aunque hay poco que el CISO podría haber hecho para evitarlo.
Aumento de vulnerabilidades
La tendencia observada es que el número de vulnerabilidades está aumentando. También hay una amplia gama de diferentes tipos de vulnerabilidad, y se han realizado esfuerzos para proporcionar clasificaciones, taxonomías y ontologías para las vulnerabilidades de seguridad.
Un propósito de la clasificación de vulnerabilidades es identificar las debilidades en el SDLC (Software Development Lifecycle) para evitar vulnerabilidades en primer lugar.
Por supuesto, es imposible evitar por completo la generación de vulnerabilidades de seguridad durante el diseño del sistema y el software. Sin embargo, el estado de la ciberseguridad se puede mejorar significativamente al reducir tanto el número como la gravedad de las vulnerabilidades de seguridad generadas.
La pregunta entonces es cómo trabajar mejor para lograr este objetivo. Se usan distintos enfoques para esta finalidad, por ejemplo, los métodos automáticos que analizan y borran código para localizar y suprimir vulnerabilidades previamente a la configuración del código en producción.
El enfoque más importante es seguir los principios para el desarrollo de software seguro y garantizar que los diseñadores de software tengan suficiente experiencia en seguridad.
Modelos de desarrollo de software
Se han propuesto y aplicado varios modelos o enfoques de desarrollo de software durante los últimos 30 años. Cada modelo tiene sus características, ventajas y desventajas, pero común a todos es que normalmente no se centran en la seguridad.
Una selección de cinco modelos de desarrollo destacados se analizan brevemente y se comparan. Estos modelos son:
- De cascada
- De iteración
- En forma de V
- Espiral
- Ágil, alias. XP (Programación extrema)
Modelo de cascada
El modelo en cascada es el enfoque clásico y más pesado para el desarrollo de software, mientras que el modelo ágil es el enfoque más ligero y flexible. Describiremos brevemente la cascada y los modelos ágiles, ya que representan enfoques muy diferentes para la programación segura.
La idea básica detrás del modelo de cascada es que las tareas de cada fase deben completarse completamente antes de la siguiente fase, que está simbolizada por la metáfora de la cascada donde el agua solo fluye hacia abajo. Esto también implica que el conjunto completo de requisitos debe definirse y fijarse al comienzo del proyecto.
En caso de que sea necesario volver a visitar una etapa anterior, entonces es de esperar una sobrecarga costosa, por lo que esto debe evitarse. Sin embargo, suele ocurrir que los requisitos tengan que cambiarse en medio de un proyecto de desarrollo de software, de modo que muchos proyectos de desarrollo de software basados en el modelo en cascada hayan sufrido grandes pérdidas de costes y tiempo.
Modelo ágil
Como reacción a la estructura rígida del modelo en cascada, se han propuesto varios otros modelos, donde el más reciente y radical es el modelo ágil (también conocido como XP).
Lo fundamental en el modelo ágil es que los nuevos requisitos pueden determinarse a la vez o después de los requisitos ya aplicados. Esto puede hacerse fraccionando el desarrollo en historias independientes. Así, cada historia abarca un conjunto de requisitos implantados como funciones que pueden desarrollarse y probarse con independencia de otras historias.
Cada iteración cíclica en el modelo ágil es un sprint que se puede completar en solo unas pocas semanas. El principal inconveniente del modelo ágil es que a menudo no se adapta bien a proyectos de desarrollo grandes y complejos.
Se deben incluir tareas específicas relacionadas con la seguridad en las diversas fases del SDLC, ya sea que el desarrollo siga el modelo en cascada, el modelo ágil o cualquier otro modelo.
Debido a la diferencia radical entre la cascada y los modelos ágiles, el equipo de desarrollo necesita adaptar el enfoque específico para asegurar el desarrollo según el modelo seguido.
Desarrollo seguro en el modelo de cascada
Existen varios modelos recomendados y de «mejores prácticas» para garantizar un desarrollo seguro, incluido el marco NIST para consideraciones de seguridad en el ciclo de vida del desarrollo del sistema, así como el ciclo de vida del desarrollo de seguridad (SDL) de Microsoft.
Tanto el modelo NIST como el modelo SDL de Microsoft se basan en el modelo en cascada para SDLC.
La fase de SDL de Microsoft es la capacitación en seguridad que enfatiza la importancia de que los programadores y otros miembros del equipo hayan adquirido habilidades de seguridad adecuadas para su trabajo. La capacitación en seguridad permite a los desarrolladores conocer las amenazas y vulnerabilidades y crear aplicaciones seguras.
En Microsoft SDL, cada fase del modelo en cascada incluye tareas relacionadas con la seguridad, como en la fase de planificación, fase de requisitos y fase de diseño. El análisis de riesgos se incluye, por ejemplo, en la fase de diseño.
La mayoría de las vulnerabilidades surgen durante la codificación. Por lo tanto, es crucial que el programador siga métodos estrictos y seguros de programación segura. Al observar la lista de los 25 errores de software más comunes, vemos que muchos de estos están directamente relacionados con la práctica de programación irresponsable o descuidada.
Desarrollo seguro en el modelo ágil
Existen relativamente pocos estudios sobre modelos de desarrollo de software ágil y seguro.
Se recomienda identificar a todas las partes interesadas y aclarar cuáles son sus principales preocupaciones de seguridad. De este análisis se pueden deducir una serie de vulnerabilidades que constituyen la base de las historias de seguridad de las partes interesadas. Luego, durante la fase de desarrollo, uno tiene sprints de seguridad periódicos entre los sprints de desarrollo regulares. También se propone incluir una revisión final de seguridad antes de implementar el sistema final.
Microsoft ha presentado una versión de SDL para el desarrollo de software ágil. El modelo SDL Agile contiene los mismos pasos de seguridad que en el modelo SDL en cascada, donde estos pasos se agrupan en 3 categorías:
- Actuaciones únicas: prácticas de seguridad fundamentales que deben establecerse una vez al comienzo de cada nuevo proyecto Agile.
- Prácticas Every-Sprint: prácticas de seguridad esenciales que se deben realizar en cada sprint.
- Prácticas de cubeta: prácticas de seguridad importantes que deben completarse de manera regular pero que pueden extenderse a través de múltiples sprints durante la vida del proyecto.
Nuestro enfoque para manejar la seguridad en el modelo ágil se basa en la distinción entre lo que llamamos controles de seguridad funcionales y controles de seguridad no funcionales.
Controles de seguridad funcionales
Estos controles reflejan e implementan historias de usuario que están directamente relacionadas con la seguridad, como cuando la administración y verificación de contraseña se usa como control para implementar una historia de usuario para el inicio de sesión. O cuando las ACL (Listas de control de acceso) se usan como un control para especificar e imponer políticas para usar varios recursos dentro de un dominio.
Controles de seguridad no funcionales
Estos controles se aplican para eliminar o mitigar vulnerabilidades en la implementación de otras historias de usuarios, como cuando se aplican técnicas de programación seguras para evitar errores de desbordamiento del búfer. O cuando se aplica un filtro de entrada al diseñar un front-end para un Base de datos SQL para evitar la inyección SQL.
El diseñador de software debe comprender que cualquier tipo de historias de usuarios, tanto historias de usuarios comunes como historias de usuarios relacionadas con la seguridad específica, deben implementarse de manera segura. La forma de hacerlo es precisamente a través de controles de seguridad no funcionales.
La idea es que las amenazas de seguridad que son intrínsecas a una historia de usuario específica se deben manejar durante el sprint para la misma historia de usuario.
Otro ejemplo de controles de seguridad no funcionales es cuando se implementa una historia de usuario sobre la lógica para manejar el pago de una cesta de la compra en un sitio web de comercio electrónico. Aquí, la amenaza podría ser que el cliente pueda engañar al sistema cambiando la cantidad de artículos después de que se haya calculado el precio, para que pueda recibir muchos artículos pero solo pagar uno.
Este problema de seguridad debe manejarse durante el sprint que implementa el pago de las cestas de compras. En base a estas consideraciones, debe introducirse una nueva fase de seguridad en la iteración de sprint. Esta fase de seguridad se enfoca específicamente en identificar amenazas contra las historias de usuarios actuales. La nueva fase también debe especificar cómo se pueden controlar o mitigar las amenazas, y debe especificar pruebas para esos controles de mitigación.
Casos irregulares
A veces puede no estar claro si un requisito de seguridad es funcional o no, en cuyo caso existe el peligro de que los requisitos de seguridad no se manejen de acuerdo con el modelo.
La pregunta es qué sucede cuando se trata de manejar la seguridad funcional como parte de otras historias de usuario, o cuando se trata de manejar la seguridad no funcional como una historia de usuario separada, que es lo contrario de lo que recomienda el modelo. Analizamos estos dos casos irregulares por separado a continuación.
Manejar un requisito de seguridad no funcional obvio como un requisito de seguridad funcional generaría una sobrecarga innecesaria. Esto se debe a que la seguridad no funcional es una parte integral de las historias de otros usuarios, por lo que si la seguridad no funcional se maneja por separado, conduciría a la repetición de esas historias de usuario. Sin embargo, los requisitos de seguridad no funcionales podrían ser adecuadamente atendidos. La conclusión es que la eficiencia del desarrollo sufriría, no la seguridad.
En caso de no manejarse los requisitos de seguridad funcionales necesarios como una historia de usuario separada, el equipo de diseño no dispone de una estrategia clara para manipular esos requisitos. Dichos requisitos de seguridad funcional podrían incluirse torpemente como una sub-historia de otras historias de usuarios. Los requisitos no serían manipulados, lo que supone un fallo grave de diseño.
En caso de duda, siempre es seguro considerar un requisito de seguridad como una historia de usuario separada. Sin embargo, para optimizar la agilidad, los requisitos de seguridad claramente no funcionales deben integrarse como parte de otras historias de usuarios relevantes siempre que sea posible.
Entrenamiento en ciberseguridad
El diseño de seguridad es un desafío y requiere fuertes habilidades para hacerlo bien. Por lo tanto, no se puede esperar que los graduados de TI sin capacitación en seguridad tengan las habilidades necesarias para desarrollar sistemas seguros.
Un enfoque típico del diseño de seguridad en la industria es permitir que los especialistas en seguridad realicen una revisión de seguridad de los sistemas que han sido desarrollados por diseñadores de software sin habilidades de seguridad. Sin embargo, este enfoque desperdicia tiempo y mano de obra. El enfoque correcto es tener diseñadores de sistemas con habilidades de seguridad que puedan identificar vulnerabilidades y escenarios de amenazas durante el diseño y el desarrollo.
Es interesante notar que el modelo SDL de Microsoft para el diseño de software seguro, se centra en la capacitación en seguridad.
En los modelos ágiles para el diseño de software seguro no existe una fase separada para la capacitación en seguridad. Se supone que los miembros del equipo ya tienen el conocimiento y las habilidades necesarias para identificar escenarios de amenazas y elaborar los controles de seguridad correspondientes para mitigar esas amenazas.
Sin habilidades de seguridad entre los miembros del equipo de desarrollo, ningún modelo ágil para el desarrollo de software seguro sería práctico. Dado que una gran proporción de estudiantes de TI hoy en día aún no tienen una exposición limitada a la ciberseguridad, practicar modelos ágiles para un desarrollo seguro es problemático. Por esta razón, existen modelos de madurez para el desarrollo de software seguro, donde los más destacados son Building Security In Maturity Model (BSIMM2) y el Open Software Assurance Maturity Model (OpenSAMM) de OWASP.
Los gobiernos u organizaciones de interés en muchos países son conscientes de esta deficiencia y, por lo tanto, han lanzado programas para fortalecer la educación sobre seguridad.
Iniciativa Nacional para la Educación en Ciberseguridad en EEUU
En EEUU, por ejemplo, NICE (Iniciativa Nacional para la Educación en Ciberseguridad) establecida en 2014 se basa en la Iniciativa Nacional de Ciberseguridad Nacional anterior que comenzó en 2008 como una iniciativa para fortalecer las habilidades de ciberseguridad en el sector del gobierno federal de los EEUU.
NICE se ha ampliado para incluir el sector comercial, donde el objetivo es fortalecer las habilidades de ciberseguridad desde las escuelas de primarioa hasta la escuela de posgrado. El objetivo de NICE es establecer un programa de educación de seguridad cibernética operativo, sostenible y en constante mejora para que la nación utilice prácticas cibernéticas sólidas que mejoren la seguridad de los EEUU.
En otros países también deberían utilizar iniciativas como NICE. Los gobiernos nacionales deberían alentar al sector de educación superior a fortalecer la educación en ciberseguridad como parte de sus programas de educación en TI.
Conclusión
Existe un consenso en la industria de que la seguridad debe ser parte del ciclo de vida del desarrollo de software. No se trata de qué modelo de desarrollo se utiliza, sino de cómo la organización puede integrar adecuadamente la seguridad en el proceso.
Un punto débil en todos los modelos es que todos dependen de que los miembros del equipo tengan las habilidades de seguridad adecuadas. No se puede esperar que cada organización deba proporcionar capacitación en seguridad a su propio personal.
Por lo tanto, la capacitación en seguridad debe ser parte de los programas de educación de TI en la educación superior. Existe una necesidad urgente de fortalecer los programas de educación de TI en todo el mundo con respecto a la ciberseguridad.
Para este propósito, sería interesante definir un modelo de madurez de educación en seguridad para el sector universitario. Si una universidad ofrece un programa de educación de TI con seguridad insuficiente, entonces esa universidad es parte del problema de causar vulnerabilidades de ciberseguridad. Es hora de que todos los institutos de educación de TI se conviertan en parte de la solución.