Es emocionante cómo diferentes disciplinas pueden fusionarse para hacer que los procesos sean más eficientes. En 2009, se acuñó el término DevOps para abordar la fricción entre los equipos de Desarrollo y Operaciones. Como resultado, la industria se movió hacia la unificación de ambos equipos para que el equipo de desarrollo fuera responsable de todo el ciclo, desde la escritura de código hasta el despliegue en producción. Por supuesto, ¿quién entendería mejor las complejidades que las personas que las desarrollaron?
Después de este cambio, hemos visto cómo se lanzan características rápidamente y el tiempo de comercialización de nuevas características ha disminuido considerablemente. DevOps también sirvió como base para muchas otras prácticas como MLOps, DataOps, GitOps, y sin duda muchas más han surgido.
Hoy hablaremos sobre una de estas prácticas con la que muchos de ustedes podrían estar familiarizados, llamada DevSecOps (Operaciones de Seguridad en el Desarrollo). Entonces, ¿qué es DevSecOps?
La seguridad ha sido tradicionalmente tratada como una reflexión tardía, con equipos que lanzan características a producción primero y luego apresurándose a implementar remedios de seguridad durante una revisión de seguridad o un incidente. Con el aumento de la ciberseguridad, la cadena de suministro y otros ataques sofisticados, la industria se dio cuenta rápidamente de que, al igual que el desarrollo y las operaciones, la seguridad también debería ser parte del proceso. Debe estar integrada en el ciclo de vida del desarrollo lo antes posible porque abordar la seguridad más tarde puede ser costoso (tanto desde el punto de vista de la arquitectura como de las operaciones).
Ahora, hablemos de cómo se puede aplicar en varias etapas de nuestro ciclo de vida de desarrollo para que el código que estamos enviando no solo sea eficiente, sino también seguro.
Por lo general, el proceso de envío de una función implica:
- Desarrollo – donde se construye la función
- Distribución – donde se crean y preparan los artefactos para la entrega
- Implementación – donde se libera la función en el entorno de producción
Hablemos de los pasos que podemos seguir para mejorar la postura de seguridad de la función que estamos construyendo durante la fase de desarrollo.
En la fase de desarrollo, una función pasa por una revisión de diseño, codificación y luego una revisión de solicitud de extracción. Como parte de la revisión de diseño, el propietario de la función discute cómo son los contratos de API, qué tipo de bases de datos estamos utilizando, estrategias de indexación, almacenamiento en caché, experiencia del usuario, y así sucesivamente (no es una lista exhaustiva). En la cultura de seguridad primero, también es importante realizar un modelado de amenazas.
Realizar Modelado de Amenazas
Simplemente pon, modelado de amenazas es “el proceso de identificar vulnerabilidades, realizar una evaluación de riesgos e implementar las mitigaciones recomendadas para que la postura de seguridad de los productos/organizaciones no se vea comprometida.”
Veamos un ejemplo para entender esto. Imagina que estás desarrollando una API que:
- Enumera productos en tu catálogo de productos.
- Busca un producto o tipo de producto.
GET /api/products?search=laptop
Un modelo de amenazas puede verse algo así:
| functionality | vulnerability | risk assessment | recommended mitigation |
|---|---|---|---|
| Los usuarios no autenticados pueden buscar productos | Los actores de amenazas pueden realizar un ataque DDoS (Denegación de Servicio Distribuido), sobrecargando la base de datos y la infraestructura de la API | Alto – Puede interrumpir el servicio y reducir la disponibilidad | Usar una Puerta de Enlace de API o un limitador de velocidad para prevenir ataques DDoS. |
| El usuario introduce una cadena de consulta en el campo de búsqueda | Puede realizar un ataque de Inyección SQL como insertar “1=1” | Alto – El atacante puede borrar la tabla de producción | Asegurarse de que se realicen validaciones/sanitizaciones adecuadas en la entrada. |
| El usuario recibe detalles del producto | Exponer campos internos como IDs de base de datos, códigos de estado y números de versión podría proporcionar a los atacantes información crítica sobre la estructura de la base de datos o del sistema subyacente. | Medio – El atacante puede utilizar estas implementaciones internas para realizar ataques como la recopilación de información | Solo envíe los detalles requeridos para el usuario. |
Estos son aspectos que podemos considerar al observar los puntos finales del producto. La mejor parte es que no necesita ser un experto en seguridad para reconocer estas vulnerabilidades.
Herramientas como Microsoft Threat Modeling Tools y OWASP Threat Dragons pueden ayudar a identificarlas.
Ejemplo de un Modelo de Amenaza en la Herramienta de Modelado de Amenazas de Microsoft
Vista de Análisis
La vista de análisis de la herramienta de modelado de amenazas muestra diferentes ataques que pueden ocurrir en la API.
Revisar el modelo de amenaza con su equipo puede actuar como una sesión de lluvia de ideas para identificar y mitigar la mayor cantidad posible de brechas de seguridad.
- Usos criptográficos débiles. Por ejemplo, el uso de SHA1 o MD5 se considera débil.CA530 es un ejemplo de una advertencia que C# crea cuando se utilizan funciones hash débiles en el código.
- Ataques de inyección SQL. CA2100 es un ejemplo que verifica si el código es susceptible a ataques de inyección
- Contraseñas codificadas, mecanismos de autenticación y autorización débiles, y configuraciones incorrectas de infraestructura también pueden ser detectados con analizadores estáticos.
También existen herramientas en este espacio. SonarQube, CodeQL, Roslyn Analyzer, OWASP Dependency Check, y Snyk tienen ofertas excelentes en este ámbito.
Integrar análisis estático en las tuberías de construcción también es importante. Ofrece ventajas como:
- Una experiencia de detección de vulnerabilidades consistente para tus desarrolladores.
- Mejora la postura de seguridad de tu servicio porque cada implementación en producción debe pasar por estos pasos.
Revisiones de Código Desde una Perspectiva de Seguridad
Si bien las revisiones de código tradicionalmente se centran en identificar errores y asegurar las mejores prácticas, es importante evaluarlo también desde una perspectiva de seguridad así. Al considerar las implicaciones de seguridad de cada solicitud de extracción, puedes prevenir proactivamente amenazas futuras y salvaguardar la integridad de tu aplicación.
Conclusión
Para concluir, con la creciente sofisticación en el panorama de la ciberseguridad, es importante considerar laseguridad en las primeras fases en lugar de dejarla para el final. Como parte deeso, incorpora modelado de amenazas y análisis estático automatizado en tu ciclo de desarrollo regular.
En los próximos artículos, discutiremos qué prácticas de seguridad podemos incorporar durante la distribución, lo que implica escanear imágenes de contenedores, pruebas de seguridad de aplicaciones dinámicas (DAST) y firma de artefactos para proteger el servicio de ataques a la cadena de suministro.
Source:
https://dzone.com/articles/building-security-into-design-phase