TecNoticias, tu portal de información

La retrospectiva es algo maravilloso. Mirando hacia atrás en las primeras etapas de DevOps, un momento de claridad 20/20 es que si las personas lo estuvieran haciendo bien desde el principio, no habría necesidad de cambiar DevOps a DevSecOps. La seguridad debería haber sido parte del enfoque desde el principio.

La seguridad siempre debe ser fundamental, pero en la prisa por desarrollar nuevas ideas o por entregar aplicaciones más rápido, es posible que se pase por alto. Esto es, irónicamente, precisamente lo que sucedió con DevOps. El establecimiento de un ecosistema de seguridad durante la etapa de desarrollo y su mantenimiento durante todo el ciclo de vida debería haberse construido desde el principio.

Sin embargo, la buena noticia es que las empresas aún pueden implementar un enfoque proactivo como el mejor método para desarrollar lo esencial de DevSecOps. De hecho, DevSecOps es más que una nueva forma de hacer de la seguridad un punto focal en cualquier práctica de DevOps. La integración de la seguridad en la base de una aplicación o programa permite a las empresas proteger sus productos y usuarios sin emitir cientos de parches y actualizaciones, lo que mejora la productividad y la seguridad.

Las amenazas del medio ambiente: limitaciones de DevOps que obligan a la evolución de DevSecOps

DevOps es un método de desarrollo muy promocionado, pero no es perfecto. Una gran área de oportunidad radica en la seguridad. La adopción de prácticas de DevOps puede generar descuidos que conduzcan a productos más vulnerables. Hay algunas razones para esto:

Planes y metas de transición mal definidos: Si todos en una organización tienen una definición diferente de lo que es DevOps, la estrategia seguramente fallará. Combinar el desarrollo de software con las operaciones es una tarea enorme, por lo que es fácil para las personas tener diferentes impresiones de lo que significa. En este conflicto radica el riesgo de brechas de seguridad, ya que ni los desarrolladores ni las operaciones saben quién es el responsable de administrarlo.

Falta de participación de los trabajadores: A menudo se considera que la tecnología es el motor de DevOps cuando, en realidad, es un proceso que gira en torno a las personas. Una cultura que está ligada a una estructura tradicional no es una que acepte fácilmente un enfoque de DevOps colaborativo. Cuando la cultura no está lista, la gente no se hará cargo de ciertas tareas fuera de su silo percibido y puede pasar por alto la seguridad.

Velocidad sin estructura: DevOps es un sistema de flujo libre que fomenta la innovación, la velocidad y la agilidad en todos los niveles de la organización. Sin embargo, esto puede conducir a una falta de gobernanza que haga que las personas eludan las políticas de seguridad y los requisitos de cumplimiento. Con una supervisión limitada, surge el riesgo de vulnerabilidades de seguridad.

Métricas ineficaces: La capacidad de equilibrar los resultados con el riesgo solo es posible con indicadores clave de rendimiento claramente definidos que muestren qué está teniendo éxito y a qué costo. Siempre hay un toma y daca entre el acceso y la protección. Las métricas ayudan a verificar el nivel correcto de equilibrio.

Si bien estas limitaciones son ciertamente preocupantes, eso no hace que DevOps sea ineficaz, solo es un caso increíblemente sólido para inyectar seguridad en la primera oportunidad. Y nuevamente, hay buenas noticias: las organizaciones que buscan hacer crecer su programa DevOps en un sistema DevSecOps que abarque completamente la seguridad solo necesitan tomar algunas medidas más.

El camino evolutivo: los pasos necesarios para pasar de DevOps a DevSecOps

El "por qué" detrás de esta evolución suele ser muy claro: las empresas que integran la seguridad en su enfoque DevOps informan que pueden resolver casi la mitad de sus problemas críticos en menos de un día. Esa es una gran mejora.

Sin embargo, incorporar seguridad puede significar muchas cosas diferentes y, por lo tanto, puede haber mucha confusión en cuanto a "cómo" evolucionar. Normalmente, si el proceso comprende reconocimiento, simplificación, automatización y medición, una organización puede disfrutar de los beneficios de DevOps sin riesgos de seguridad.

Reconocimiento: Las organizaciones deben reconocer los datos que tienen, el riesgo que presentan y las amenazas actuales para su industria. Se necesita una comprensión clara de las regulaciones, los requisitos de cumplimiento y las leyes para incorporar la gobernanza en el ecosistema. La inteligencia sobre amenazas cibernéticas proporciona conciencia de los riesgos a medida que surgen. El etiquetado de datos preciso establece niveles de confidencialidad adecuados según la necesidad.

La transparencia del programa hace visibles las anomalías dentro del sistema y acelera la respuesta. Los registros inmutables y la supervisión constante ayudan a descubrir y solucionar problemas operativos y de seguridad. Todos estos componentes se unen para crear el conocimiento necesario para reconocer los indicadores de riesgo.

Simplificación: Las tareas simples suelen ser las mejores, ya que conducen a procesos repetibles y manejables. Un buen ejemplo es Infraestructura como código (IaC). El código repetible y simplificado permite a las organizaciones escalar su infraestructura mientras protege los datos que contiene. Como la complejidad es baja, también lo es el riesgo de error humano.

La orquestación de seguridad podría caer bajo el paraguas de "simplificar" porque se trata de convertir cien procesos diferentes en uno solo centralizado. Las distintas herramientas del centro de operaciones de seguridad se combinan y las tareas se completan en una consola consolidada.

Automatización: La entrega e implementación continuas son un método de automatización forzada en todas las partes del ciclo de vida del desarrollo. Las pruebas se realizan de forma sistemática y permiten a los desarrolladores identificar y corregir problemas como vulnerabilidades y debilidades en una etapa más temprana del ciclo de vida del desarrollo de software. La automatización captura los problemas cuando aún son pequeños y fáciles de corregir antes de filtrar por toda la aplicación.

Esta área también elimina el riesgo de error humano, una de las mayores amenazas para el proceso de desarrollo. Las herramientas como las pruebas de seguridad de aplicaciones estáticas y las pruebas de seguridad de aplicaciones dinámicas se producen durante las compilaciones, la preparación y el lanzamiento para garantizar la entrega del mejor código posible.

Medición: La medición no es algo que deba ocurrir en la etapa final. Debe ocurrir de manera consistente durante todo el ciclo de vida del programa, evaluando elementos como la frecuencia de implementación, el tiempo de espera para los cambios, la tasa de fallas de cambios y el tiempo para restaurar el servicio. De esta forma, los administradores pueden aprovechar las oportunidades para optimizar las tareas, mejorar la eficiencia y minimizar las amenazas. Ningún programa de seguridad es perfecto, pero la medición constante lo acerca lo más posible.

Encontrar el mejor socio de seguridad para su empresa

Por supuesto, la mejor manera de convertir DevOps en DevSecOps es tener una auditoría completa de terceros. Con el ojo crítico de un experto imparcial, es posible realizar mejoras y oportunidades de mejora. La auditoría funciona en conjunto con el programa DevOps existente para un enfoque holístico de la seguridad de un extremo a otro.

Nota del editor: lea las últimas noticias de DevOps sobre la publicación hermana CloudTech.

¿Está interesado en escuchar a los líderes de la industria discutir temas como este? Asista a la 5G Expo, IoT Tech Expo, Blockchain Expo, AI & Big Data Expo, y Cyber ​​Security & Cloud Expo World Series, ubicadas en el mismo lugar, con los próximos eventos en Silicon Valley, Londres y Ámsterdam.