¿Has entrevistado últimamente para trabajos en tecnología e IT? Es una experiencia iluminadora.
La mayoría de Juniors que entran a una entrevista han acabado recientemente su grado en informática. Acostumbra a ser o una ingeniería, o un grado superior en administración de sistemas. Las clases por las que han pasado son mayormente lo que se podía esperar: estructuras de datos, algo de programación, cálculo de coste de procesos, configurar máquinas virtuales, administración de servicios, funcionamiento de un centro de datos para asegurar disponibilidad, quizá algo de seguridad red-team o blue-team…
O quizá ya no eres tan junior y vienes con algo de experiencia bajo el cinturón, pero llevas un poco más de tiempo del que te gustaría sentado en una silla de oficina instalando drivers de impresora y mirando un panel de Zabbix, y quieres un poco de aire fresco, un reto profesional. En ambos casos probablemente te encuentres con que los tiempos han cambiado. Han cambiado bastante.
Visitando terrenos inexplorados
Lo primero que probablemente notes cuando explores LinkedIn es que los administradores de sistemas están un poco pasados de moda. Las empresas ya no buscan un sysadmin, o mejor dicho, no buscan sólo un sysadmin. Eso está separado de otros equipos como los developers en lo que se llama un «silo», y los «silos» son muy last-gen. El último grito es ser DevOps!
En tu búsqueda de algo nuevo, o como mínimo por ósmosis de esos posts de influencers de Linkedin, probablemente hayas oído antes el concepto de DevOps. Hemos explicado esta filosofía antes en el blog de geko, pero hagamos un recordatorio rápido: DevOps es esencialmente una filosofía, una forma de trabajar en equipo, que une esos «silos» en un solo equipo interconectado que trabaja en sintonía para hacer delivery más rápida y eficiente, más ágil y más automatizado. No más Patch Tuesdays, no más miedo de desplegar los viernes!
Esto es algo generalizado, y quizá cuesta focalizarte en un área de trabajo cuando los silos ya no existen. Si estás buscando un reto nuevo en esta industria hay muchas posibilidades de que te interese el campo de la ciberseguridad. Es un área en vías de crecimiento, hay mucho trabajo disponible, conlleva algo distinto cada día… ¡Parece todo positivo! (mientras la empresa haga caso a tus recomendaciones, claro), pero también probablemente hayas notado que la ciberseguridad es uno de los campos que más cambian en la industria. Es un trabajo que debe evolucionar siempre con todos los demás campos de IT, generalmente un paso por delante incluso, porque tiene que proteger todos los nuevos escenarios de trabajo que se presenten. Si DevOps une todos los campos del proceso de desarrollo, seguridad debe poder proteger todos los campos del desarrollo.
¿Qué tienen que ver entre ellos?
Si sigues la idea de pensamiento DevOps e intentas darle una vuelta al proceso de proteger recursos, probablemente en seguida te darás cuenta de que DevOps y la ciberseguridad son una muy buena pareja. Integrar todos los tests de seguridad en el proceso de desarrollo evita que esos errores lleguen a producción. Definir requisitos de seguridad en el desarrollo implica que esos problemas de seguridad no pueden llegar nunca a producción porque harán fallar la pipeline como requisito no cumplido. Tiene sentido que si se crea ese requisito en el proceso de desarrollo luego no tendrás que hacer ese trabajo en producción, o aún mejor, un threat actor no podrá aprovecharlo.
Esta vía de pensamiento creó recientemente un nuevo espacio de trabajo en el equipo de DevOps para acomodar la seguridad en operaciones, al que dimos el nombre de DevSecOps, porque a la industria tecnológica le pagan por producir servicios de calidad, no por inventarse nombres complicados. Al menos no dejamos a AWS ponerle el nombre y no tenemos que aguantarnos con algo como AWS DSO o algo así… Por ahora.
Definamos un poco más el concepto. DevSecOps, como su nombre fácil de reconocer presenta, consiste en ser una cultura que mete prácticas y requisitos de seguridad en el centro del proceso de desarrollo de DevOps. Se introducen controles de seguridad en todos los pasos de desarrollo de un producto, desde hardening de infraestructura como código (normas de firewall demasiado permisivas, volúmenes sin encriptar…) hasta análisis de código estático con herramientas automatizadas. Si los requisitos de seguridad no se cumplen, el proceso se para y hay que arreglar ese problema. Si te alertan en el proceso de desarrollo no necesitas detectarlo y arreglarlo después en producción!
Me gusta la idea. ¿Cómo lo implemento?
Toda la idea se puede resumir en un concepto: La seguridad no es un botón que puedas apretar para encenderla. No puedes aplicar seguridad a tu producto o servicio de forma eficiente instalando el software que te han dado en una call de ventas por Meet. La seguridad es una cultura. Un proceso contínuo que se construye directamente como parte de todo tu ciclo de desarrollo. Preferiblemente esto lo harás con checks automáticos del sistema que notifique de los cambios necesarios al equipo. No se despliegan aplicaciones inseguras en este equipo de operaciones.
Pero volviendo a lo de antes, no tiene por qué requerir siquiera intervención del equipo de Operaciones, quizá tu sistema avisa directamente al developer de la vulnerabilidad para que la arregle. Trabajo ágil, menos esperar a enviar correos de tickets y más entregar productos de valor! Toda la filosofía está pensada para cohesionar los departamentos y equipos y acelerar su trabajo eliminando pasos innecesarios.
¿Mi infraestructura es demasiado vieja escuela para esto, no?
Incluso en caso de que tu infraestructura sea demasiado legacy para adaptarse a la filosofía DevOps, las prácticas de seguridad que implica DevSecOps sigue siendo importante y debería trabajarse aplicar todas las posibles. ¿Administras algunos servidores con playbooks de Ansible? Quizá deberías pasar las repos por un pre-commit hook que compruebe que no has pusheado claves privadas. ¿Tienes una imagen de docker propia para alguna tarea concreta? ¿Por qué no pasarla por un analizador de imágenes, como Snyk o docker scan? (¿Sabías que Docker tenía un escáner de vulnerabilidades en imágenes? yo no). ¿Estás moviendo partes de tu infraestructura al cloud y quieres que sea fácilmente reconstruible con Terraform? Bridgecrew integra con casi cualquier provider para alertarte de ese «allow tcp/22 from 0.0.0.0/0» que se te ha colado.
Cualquier pequeño paso es un gran movimiento en pos de hacer a tus developers la vida un poco mas fácil, y a que tu equipo de operaciones y sistemas no les toque correr a arreglar deuda técnica para que puedan centrarse en tareas realmente importantes en tu organización. Si te preocupa el coste de implementar todos estos cambios puedes tener claro que aplicarlos ahora es la solución más barata que tienes. Quizá no lo parezca ahora, pero definitivamente un puñado de alertas de Security Hub van a ser más baratas que una multa de la Ley Europea de Protección de Datos.
Me gusta, hablemos.
¿Eres alguien de la industria que busca un nuevo reto donde poder tocar todas estas tecnologías? En Geko estamos siempre a la caza de talento de todos los perfiles de senioridad, sea para traer tus conocimientos o para aprender nuevos.
¿Estás en un entorno que se beneficiaría de todo esto y no sabes por dónde empezar? Contáctanos, aquí en Geko somos expertos en DevOps y transformación digital y microservicios. Hablemos sin compromiso de cómo podemos llevar a tu equipo a una gestión mejor.[:]