Comprensión de las consideraciones sobre seguridad para las soluciones de administración del ciclo de vida de las aplicaciones

El Ciclo de vida de desarrollo de seguridad de Microsoft (SDL) introduce consideraciones sobre seguridad y privacidad en todas las fases del proceso de desarrollo. Ayuda a los desarrolladores a crear software altamente seguro, abordar los requisitos de cumplimiento de seguridad y reducir los costos de desarrollo. Las guías, procedimientos recomendados, herramientas y procesos de SDL son prácticas que se usan internamente en Microsoft para crear productos y servicios más seguros.

Desde la primera vez que compartimos SDL en 2008, las prácticas se han actualizado continuamente para abarcar nuevos escenarios, como servicios en la nube, IoT e IA.

Formación

La seguridad es trabajo de todos los usuarios. Los desarrolladores, ingenieros de servicio y jefes de proyectos y de programas deben conocer los aspectos básicos de la seguridad. Todos ellos deben saber cómo compilar la seguridad en el software y los servicios para que los productos sean más seguros, a la vez que satisfacen las necesidades empresariales y entregan el valor de usuario. Un entrenamiento eficiente complementará y reforzará las directivas de seguridad, prácticas de SDL, estándares y requisitos de seguridad de software, y se guiará por información obtenida a través de los datos o las capacidades técnicas nuevas disponibles.

Aunque la seguridad es un trabajo que recae en todos los usuarios, cabe recordar que no todos deben ser expertos en seguridad ni esforzarse en llegar a ser un evaluador de pruebas de penetración experto. Sin embargo, garantizar que todos entiendan la perspectiva del atacante, sus objetivos y el arte de lo posible ayudará a captar la atención de todo el mundo y a aumentar la base de conocimiento colectiva.

Definición de requisitos de seguridad

Tener en cuenta la seguridad y la privacidad es un aspecto fundamental para desarrollar aplicaciones y sistemas muy seguros. Independientemente de la metodología de desarrollo que se use, los requisitos de seguridad se deben actualizar continuamente para abordar los cambios en la funcionalidad necesaria y en el escenario de las amenazas. Obviamente, el momento óptimo para definir los requisitos de seguridad es durante las fases iniciales de diseño y planificación, ya que la planificación inicial permite a los equipos de desarrollo integrar la seguridad de maneras que minimizan la interrupción.

Algunos de los factores que afectan a los requisitos de seguridad son los siguientes:

  • Requisitos legales y del sector
  • Estándares internos y procedimientos de codificación
  • Revisión de los incidentes anteriores
  • Amenazas conocidas

Se debe realizar un seguimiento de estos requisitos a través de un sistema de seguimiento de trabajo o de la telemetría que se deriva de la canalización de ingeniería.

Definición de métricas e informes de cumplimiento

Es fundamental que las organizaciones definan los niveles mínimos aceptables de calidad de seguridad y que los equipos de ingeniería mantengan la responsabilidad de cumplir esos criterios. La definición de estas expectativas ayuda en una fase temprana a los equipos a comprender los riesgos asociados a las incidencias de seguridad, identificar y corregir los defectos de seguridad durante el desarrollo y aplicar los estándares en todo el proyecto. Establecer una barra de seguridad significativa implica definir claramente los umbrales de gravedad de las vulnerabilidades de seguridad y ayuda a establecer un plan de acción cuando se encuentran las vulnerabilidades. Por ejemplo, todas las vulnerabilidades conocidas que se detecten con una clasificación de gravedad "crítica" o "importante" deben corregirse en un período de tiempo específico.

Para realizar el seguimiento de los indicadores clave de rendimiento (KPI) y asegurarse de que se completan las tareas de seguridad, el seguimiento de errores y los mecanismos de seguimiento del trabajo que usa una organización (como Azure DevOps) deben permitir que los defectos de seguridad y los elementos de trabajo de seguridad se etiqueten claramente como seguridad, y se marquen con la gravedad de seguridad adecuada. Esto permite un seguimiento preciso y la generación de informes de trabajo de seguridad.

Puede obtener más información sobre cómo definir métricas e informes de cumplimiento en los siguientes recursos:

Realización del modelado de amenazas

El modelado de amenazas debe usarse en entornos en los que haya un riesgo de seguridad considerable. Como práctica, permite a los equipos de desarrollo tener en cuenta, documentar y analizar las implicaciones de seguridad de los diseños en el contexto de su entorno operativo planificado de forma estructurada. Aplicar un enfoque estructurado a los escenarios de amenaza ayuda a los equipos a identificar de forma más eficiente y económica las vulnerabilidades de seguridad, determinar los riesgos derivados de esas amenazas y, después, realizar las selecciones de las características de seguridad y establecer las mitigaciones adecuadas. Se puede aplicar el modelado de amenazas en el nivel de componente, aplicación o sistema.

Puede encontrar más información disponible en Modelado de amenazas.

Establecimiento de requisitos de diseño

El SDL suele considerarse como varias actividades de seguridad que ayudan a los ingenieros a implementar características más seguras, lo que significa que las características están bien diseñadas con respecto a la seguridad. Para lograrlo, los ingenieros suelen basarse en características de seguridad como la criptografía, la autenticación y el registro. En muchos casos, la selección o la implementación de las características de seguridad han demostrado ser tan complicadas que las opciones de implementación o diseño pueden dar lugar a vulnerabilidades. Por lo tanto, es fundamental que se apliquen de forma uniforme y con una comprensión coherente de la protección que proporcionan.

Definición y uso de estándares de criptografía

Con el aumento de la informática móvil y en la nube, es importante garantizar que todos los datos, incluida la información confidencial de seguridad y la administración y el control de los datos, se protejan contra la modificación o divulgación no intencionadas cuando se transmiten o almacenan. Normalmente, el cifrado se usa para lograr esta protección. Pero una elección incorrecta al usar cualquier aspecto de la criptografía puede tener un resultado catastrófico. Por lo tanto, es mejor desarrollar estándares de cifrado claros que proporcionen información específica sobre cada elemento de la implementación del cifrado.

El cifrado debe estar en manos de expertos. Una regla general correcta consiste en usar solo las bibliotecas de cifrado que haya revisado el sector y asegurarse de que se implementan de forma que se puedan reemplazar fácilmente en caso necesario.

Para obtener más información sobre el cifrado, consulte el documento técnico Recomendaciones criptográficas de Microsoft SDL.

Administración de los riesgos de seguridad mediante el uso de componentes de terceros

La gran mayoría de los proyectos de software de hoy en día se compilan mediante el uso de componentes de terceros (tanto comerciales como de código abierto). Al seleccionar los componentes de terceros que se van a usar, es importante comprender el impacto que podría suponer en estos una vulnerabilidad de seguridad en la seguridad del sistema más grande en el que están integrados. El hecho de tener un inventario preciso de estos componentes y un plan para responder cuando se descubran nuevas vulnerabilidades allanará el camino hacia la mitigación de los riesgos. Sin embargo, también debe tener en cuenta la validación adicional, según la aversión al riesgo de su organización, el tipo de componente que se utiliza y el impacto potencial de una vulnerabilidad de seguridad.

Obtenga más información sobre la administración de los riesgos de seguridad al usar componentes de terceros en los siguientes recursos:

Uso de herramientas aprobadas

Defina y publique una lista de herramientas aprobadas y sus comprobaciones de seguridad asociadas, como las opciones y advertencias del compilador y el enlazador. Los ingenieros deben esforzarse por usar la versión más reciente de las herramientas aprobadas (como las versiones de compilador) y utilizar nuevas capacidades y protecciones de análisis de seguridad.

Para obtener más información, consulte:

Realización de pruebas de seguridad de análisis estático

Analizar el código fuente antes de la compilación proporciona un método muy escalable de revisión de código de seguridad y ayuda a garantizar que se siguen las directivas de codificación segura. Las Pruebas de seguridad de análisis estático (SAST) normalmente se integran en la canalización de confirmación para identificar las vulnerabilidades cada vez que se compila o empaqueta el software. Pero algunas ofertas se integran en el entorno del desarrollador para detectar ciertos errores, como la existencia de funciones no seguras u otras funciones prohibidas y, luego, reemplazarlas por alternativas más seguras mientras el desarrollador diseña el código de forma activa. No existe una solución única; los equipos de desarrollo deben decidir la frecuencia óptima para realizar las pruebas SAST y considerar la posibilidad de implementar varias tácticas para equilibrar la productividad con una cobertura de seguridad adecuada.

Puede encontrar más información disponible en los siguientes recursos:

Realización de pruebas de seguridad de análisis dinámico

La comprobación en tiempo de ejecución del software totalmente compilado o empaquetado realiza la comprobación de la funcionalidad que solo es aparente cuando todos los componentes están integrados y en ejecución. Esta comprobación se consigue mediante una herramienta, un conjunto de ataques compilados previamente o herramientas que supervisan específicamente el comportamiento de la aplicación en busca de daños en la memoria, incidencias de privilegios de usuarios y otros problemas de seguridad críticos. Como sucede con las pruebas SAST, no existe una solución única y, mientras que algunas herramientas (como las de examen de aplicaciones web) se pueden integrar más fácilmente en la canalización de CI/CD, otras Pruebas de seguridad de aplicaciones dinámicas (DAST), como la aplicación de pruebas de vulnerabilidad ante datos aleatorios o inesperados, requieren otro enfoque.

Puede encontrar más información disponible en los siguientes recursos:

Realización de pruebas de penetración

La prueba de penetración es un análisis de seguridad de un sistema de software que lo realizan profesionales de seguridad experimentados que simulan las acciones de un hacker. El objetivo de una prueba de penetración es revelar posibles vulnerabilidades derivadas de errores de codificación, errores de configuración del sistema u otros puntos débiles de la implementación operativa. Las pruebas de penetración suelen encontrar la variedad más amplia de vulnerabilidades y normalmente se realizan junto con las revisiones de código automatizadas y manuales para proporcionar un mayor nivel de análisis del que normalmente sería posible.

Puede encontrar más información disponible en los siguientes recursos:

Establecimiento de un proceso de respuesta estándar a los incidentes

La preparación de un plan de respuesta a incidentes es crucial para enfrentarse a las nuevas amenazas que puedan surgir con el tiempo. Debe crear su plan en coordinación con el Equipo de respuesta a incidentes de seguridad de productos (PSIRT) de su organización. El plan de respuesta ante incidentes debería:

  • Incluir la información de contacto de la persona a la que se deberá acudir si se produce una emergencia de seguridad.
  • Establecer el protocolo para el servicio de seguridad, incluidos los planes para de código heredado de otros grupos de la organización y para el código de terceros.
  • Probarse antes de que sea necesario.

Para obtener más información sobre las respuestas a los incidentes, consulte lo siguiente:

Mediante la inclusión de consideraciones sobre seguridad y cumplimiento normativo en todas las fases del proceso de desarrollo, los desarrolladores pueden reducir la probabilidad de que se produzcan vulnerabilidades en los productos y servicios, y evitar la repetición de los mismos errores de seguridad. Del mismo modo, la integración de seguridad en todo el ciclo de vida de las operaciones ayudará a mantener la integridad de esos productos y servicios. Los procedimientos de garantía de seguridad operativa deben alinearse con sus procesos de desarrollo; esto dará como resultado una inversión menor de tiempo y dinero en la evaluación de prioridades y respuesta posterior. Además, proporcionará a sus clientes la tranquilidad de saber que sus productos son muy seguros.