Cómo gestionar los riesgos de seguridad y la gobernanza basados en la nube

Al mismo tiempo que ofrece eficiencias empresariales, ventajas de costes y ventajas competitivas, el cambio a servicios basados en la nube (es decir, Azure, AWS y Google Drive) tiene sus propias implicaciones, no menos importante es la seguridad. Muchos asumen que el cambio a servicios basados en la nube y el uso de sus herramientas de seguridad solucionarán vulnerabilidades o deficiencias de seguridad preexistentes, pero esto simplemente no es así.

Las nubes públicas proporcionan seguridad perimetral para los datos almacenados en sus centros de datos, lo que es una función importante. Pero esta es solo una de las muchas consideraciones a la hora de garantizar la seguridad.

Los CIO suelen hablar de la necesidad de crear contenedores seguros para acelerar la velocidad de comercialización. Aunque recientemente el espacio en la nube se ha centrado en Kubernetes y la contenedorización, no pierdamos el bosque por los árboles. Las necesidades de seguridad son muy amplias y Kubernetes es solo una pequeña parte de esa ecuación.

Otros componentes críticos incluyen consideraciones de cumplimiento, automatización de DevOps y la creación de una plataforma de pruebas sólida que incluya el escaneado de vulnerabilidades estático (en comparación con el dinámico).

Consideraciones de conformidad

Varios sectores verticales (por ejemplo, la atención sanitaria) tienen sus propios estándares de cumplimiento complejos y rígidos que se sabe que son costosos y difíciles de mantener. Y actualizar las aplicaciones y la infraestructura para cumplir con los estándares de cumplimiento a menudo le deja propenso a diversas vulnerabilidades de seguridad y cumplimiento.

Pero, como he escrito anteriormente, puede combatir las vulnerabilidades invirtiendo en automatización y escaneo de seguridad para el desarrollo y la implementación de código. La automatización de estos procesos significa un acceso más rápido a la información que puede identificar vulnerabilidades de seguridad para que pueda responder a ellas de forma más eficiente.

Una vez que identifique sus vulnerabilidades de seguridad, solo es natural preguntarse qué funciones de seguridad podrían cumplir sus servicios basados en la nube y de las que aún tendrá que mantener la responsabilidad. Como explicóun compañero de Unisys, la realidad es que la seguridad en la nube es una responsabilidad compartida.

Como he señalado, los proveedores de servicios basados en la nube suelen gestionar la seguridad perimetral de los datos que almacenan en sus centros de datos, así como los controles de cumplimiento limitados para la infraestructura. Sin embargo, para cada aplicación que eleve a la nube, es responsable de configurar los controles de seguridad adecuados, identificar y certificar el cumplimiento de los requisitos de cumplimiento y gestionar el ciclo de vida de los datos.

Si parece que hay mucho con lo que luchar, es porque lo es.

Entonces, ¿cómo puedes facilitarlo? Utilizando la automatización.

Cultura de automatización de DevSecOps

Evaluar su red y aplicaciones de forma continua e informar sobre cualquier incumplimiento o riesgo potencial que identifique es un proceso increíblemente tedioso y tradicionalmente manual. Imagínese derramar más de decenas, si no cientos, de estándares de conformidad, asegurarse de que se cumple cada uno de ellos y conocer las ramificaciones si no se cumplen esos estándares.

Uno de los retos a la hora de integrar la seguridad es cambiar la mentalidad de la organización. Con la cultura DevSecOps, los desarrolladores no solo son “conscientes de la seguridad”, sino que también pueden actuar como primera línea de defensa. Comprender que es necesaria una cultura consciente de la seguridad para que los miembros de todos los equipos funcionales informen de posibles anomalías. Traducir los controles aplicables (política como código) en componentes de software adecuados como parte del proceso SDLC en evolución.

Sin embargo, esta es una receta para los errores, que podrían conllevar una multa considerable.

En lugar de exponerse a riesgos de responsabilidad innecesarios, cree una cultura de automatización de DevSecOps. Al automatizar la generación de informes y la supervisión de riesgos, se asegurará de que su red y sus aplicaciones estén supervisadas constantemente.

Pruebas como servicio

Puede que piense que la automatización es excelente, pero la supervisión constante de los riesgos es costosa y requiere que la construya desde cero. Por eso, debe considerar las pruebas como un servicio.

Las pruebas como servicio le permiten contratar a una organización central para que gestione el equipo de pruebas en nombre de su empresa. Dichas pruebas no son específicas de la seguridad. También se puede aplicar a la integración, la regresión, el rendimiento y mucho más. Por lo general, es más rentable que crear la infraestructura y la organización alrededor de una plataforma de pruebas tan robusta internamente.

No es necesario empezar desde cero cuando puede comprar capacidades de pruebas listas para usar a un proveedor externo o, mejor aún, pedirle al proveedor que cree un programa de pruebas específico para su empresa.

Por ejemplo, pídales que estandaricen las plantillas de pruebas como servicio de principio a fin (planificación, ejecución e informes de pruebas) con la reutilizabilidad, la capacidad de mantenimiento y la reducción de costes como objetivos principales. Esto le dará la flexibilidad de ampliar las capacidades sin ningún bloqueo de proveedores y se asegurará de desafiar a los proveedores de la nube pública para que hagan el trabajo pesado por usted. Podrían crear un marco como el siguiente para usted:

• Marco: Marco de modelo de objeto de página Maven
• Lenguaje de programación: Java
• Plataformas: aplicación web (Selenium), móvil (Appium), pruebas de API (REST Assured), base de datos (PostgreSQL)
• Pruebas: rendimiento (Jmeter), seguridad mediante escaneado de vulnerabilidades estático y dinámico (Veracode)
• Informes: Informe de extensión, Log4J
• CI (integración continua) y CD (implementación continua): Azure DevOps

Cuando cree su estrategia en torno a las pruebas de posibles vulnerabilidades, también tendrá que sopesar los pros y los contras del escaneado dinámico o estático.

El escaneado estático se realiza con la aplicación apagada e implica el examen del código fuente o de los binarios de la aplicación para identificar vulnerabilidades de seguridad. Si está examinando millones de líneas de código, este proceso puede volverse rápidamente engorroso y altamente ineficiente.

El escaneado dinámico se produce mientras la aplicación se está ejecutando y implica manipular la aplicación (como se utilizaría en el mundo real) para descubrir áreas de riesgo. Esto tiende a ser más exhaustivo, pero también es una forma ineficiente de escanear, ya que he descubierto que 10 millones de líneas de código pueden tardar más de un mes.

La conclusión no es decidir entre el escaneo estático y el dinámico. Es que debe comprender la necesidad de desafiar a los proveedores de pruebas para desarrollar una mejor alternativa. Esta alternativa podría ofrecerse mediante innovación tecnológica o mejoras en su escaneo dinámico. Las empresas también desempeñan un papel en la optimización del escaneado de seguridad, incluida la refactorización y modernización de su código.

Pero si solo hay una lección que puede aprender de este artículo, es que debe asumir el control de la seguridad continua de sus aplicaciones en la nube. Evite repetir lo que ha hecho con las implementaciones locales heredadas. Las partes interesadas en seguridad con visión de futuro entienden que la mejor manera de evitar el riesgo de responsabilidad futura es implementar un programa de seguridad sólido desde el principio.