Un día en la vida de un administrador de DevSecOps


«La mayoría de los días son buenos», dice Ari Kalfus de Rally Wellness. Pero seguro que están ocupados, le dice a The Edge.

Ari Kalfus es gerente de DevSecOps en la empresa de salud electronic Rally Overall health. Dirige la dirección de seguridad de aplicaciones para la empresa y coordina sus programas de pruebas de penetración internas y externas.

Lectura oscura: ¿Cuáles son algunas de las primeras cosas que hace cuando llega al trabajo?
Ari Kalfus: Revise mi correo electrónico, revise las notificaciones de Slack, planifique cuál gif de PG Strategies Quiero agregar a mis notas standup asincrónicas.

DR: Cuando comienza su día, ¿se siente bien con lo que tendrá que enfrentar en el trabajo? ¿O preocupado?
ALASKA:
La mayoría de los días son buenos. Creo que esto realmente depende de la cultura de la empresa para la que trabaja más que de algo específico de la práctica de DevSecOps. Si cuenta con el apoyo de su empresa, no necesariamente importa que tenga un montón de espinas que arrancar durante la jornada laboral. Pero si no cuenta con el apoyo de su entorno de trabajo, las tareas más triviales serán irritantes.

DR: Divida su día por nosotros.
ALASKA:

10 a. M. Es hora de empezar a trabajar. Participo en la reunión de sincronización de líderes de seguridad y discuto cualquier tema de interés principal para nuestro departamento esta semana. Durante las próximas dos horas, es posible que tenga conversaciones individuales con mi equipo o con socios en otras áreas de la organización, o tal vez una o dos horas para avanzar en una tarea técnica individual.

¡Almuerzo! Mi compañero exclama por la poca agua que he bebido en lo que va del día. Yo solía ser el que la miraba mordazmente mientras llenaba mi botella de agua una vez más. La pandemia nos ha afectado a todos.

Tarde Por lo typical, la tarde se programa con varias reuniones con grupos que buscan información sobre la seguridad de la aplicación para un problema en el que están trabajando, comunicándose con otros grupos en un esfuerzo de DevSecOps que se extiende por toda la organización, o tal vez tiempo de enfoque dedicado para pensar y hacer más. planes a más largo plazo para el programa appsec o abordar un problema de ingeniería particularmente espinoso para salvar a mi equipo.

DR: ¿Hay áreas de enfoque en unique o señales de alerta que le indiquen que puede ser un día difícil en el trabajo?
ALASKA: Esta puede ser solo mi opinión individual sobre la seguridad de las aplicaciones, pero creo que un componente de DevSecOps es garantizar que las prácticas de seguridad que requerimos de ingeniería reduzcan de manera demostrable el riesgo comercial. Algunos días, tengo reuniones con clientes externos, personas de cumplimiento u otras personas que no necesariamente están de acuerdo. Esos días siempre son difíciles.

DR: ¿Ejemplos, por favor?
ALASKA: No me importa, por ejemplo, que un servicio interno use TLS 1.1 para hablar con otro servicio interno. (Este es un ejemplo fabricado). Sería genial si se cambiaran al estándar de la empresa de 1.2, pero no voy a estar en la cima del equipo para migrar. Me importa que esos dos servicios cifren datos confidenciales a través de ese canal de comunicación, por lo que quiero asegurarme de que estén usando la biblioteca criptográfica que mantiene nuestro equipo de DevSecOps.

Sin embargo, para algunas personas, un número superior a cero en un informe significa malo. ¡Cero significa bueno! Es difícil llegar a un entendimiento común y un camino a seguir en esas conversaciones. Creo que un principio definitorio cuando se trata de DevSecOps efectivo en comparación con los enfoques de seguridad de aplicaciones más tradicionales es la aceptación de que el contexto es importante, y debemos priorizar nuestro tiempo y nuestros esfuerzos de acuerdo con ese contexto.

DR: ¿Qué hace realmente un equipo de DevSecOps?
ALASKA: El objetivo de un equipo de DevSecOps, en mi opinión, es integrar la seguridad de las aplicaciones en el desarrollo a través de la habilitación, la iteración y la retroalimentación continua, también llamado a veces «cambiar la seguridad a la izquierda». Esto requiere hablar con otras personas y asegurarse de poder ofrecerles algo que resuelva su problema mientras les permite resolver el de ellos.

Nadie quiere «dejar» de producir valor para ocuparse de los problemas de seguridad, que a menudo puede ser lo que se siente al interactuar con los equipos de seguridad. Todos ya tienen una hoja de ruta completa. ¿Por qué es necesario abordar ahora este problema de seguridad? A través de una filosofía DevSecOps, que principalmente significa tomar principios ágiles de la ingeniería y aplicarlos al trabajo de seguridad, utilizo esos días de reuniones antes mencionados para determinar cómo se puede mitigar o erradicar un problema de seguridad en distinct sin agregar fricción al proceso de desarrollo.

DR: ¿Cómo haces eso? ¿Abordar la seguridad, evitar fricciones, hacer felices a todos?
ALASKA: Esto significa ignorar muchas de las prácticas de seguridad de aplicaciones heredadas más tradicionales, como los análisis estáticos que tardan horas y en su mayoría producen falsos positivos, a favor de productos o implementaciones personalizadas que están altamente dirigidas a clases específicas de vulnerabilidades presentes en nuestro entorno.

Nuestro equipo de DevSecOps, por ejemplo, puede escribir una biblioteca de criptografía para ingeniería que utilice bibliotecas estándar de manera adecuada, evitando errores de implementación comunes que podrían conducir a la exposición de datos.

A veces podemos exigir un enfoque particular, pero normalmente ofrecemos una biblioteca como esta a la ingeniería y la vendemos para ahorrarles tiempo de desarrollo. «¡No lo hagas tú mismo! ¡Simplemente llama al método de la biblioteca y sigue adelante con tu hoja de ruta! Por cierto, haz esto y nuestras preocupaciones de seguridad de protección de datos se resolverán». Esto permite a los ingenieros producir sus funciones más rápidamente y al mismo tiempo eliminar en gran medida un problema de seguridad specific de nuestro entorno.

Esto solo funciona si la biblioteca o el proceso que ofrece Realmente facilita el desarrollo a los ingenieros. Por lo tanto, el trabajo de mi equipo es una colaboración con los ingenieros de nuestra organización para garantizar que las bibliotecas, los productos y las herramientas que ofrecemos a la ingeniería cumplan su propósito: eliminar clases de problemas de seguridad y, al mismo tiempo, permitir que la ingeniería realice su trabajo con menos fricciones.

DR: Así es como haces felices a los ingenieros. ¿Qué hay de mantener feliz a tu propio equipo?
ALASKA: El otro lado de esto es que el equipo de DevSecOps / Appsec será muchos órdenes de magnitud más pequeño que la organización de ingeniería. Para ser efectivos en la entrega de soluciones, necesitamos minimizar la cantidad de carga operativa que nuestras soluciones crean para nuestro equipo.

Por lo typical, esto significa recurrir a herramientas nativas de la nube que nos permiten ofrecer funcionalidad mientras minimizamos la sobrecarga operativa: integre webhooks y ofrezca API que activen las funciones de AWS Lambda, por ejemplo, que nos permitan escalar en toda la ingeniería sin agregar la carga de administrar servidores. o lidiar con una capacidad de carga limitada. No estoy afirmando que las herramientas nativas de la nube sean soluciones mágicas, pero permiten arquitecturas que minimizan nuestra sobrecarga más allá de lo que pueden hacer los servidores tradicionales. Todavía tenemos nuestra parte de errores.

Si bien no diría que un equipo de appsec tiene más «clientes» que un equipo de ingeniería (es de esperar que usted tenga más clientes que paguen que ingenieros en su empresa), nuestros clientes se sientan, física o virtualmente, junto a nosotros, así que si produzca contenido que no sea confiable o induce fricción, ¡nos enteraremos! Por lo tanto, debemos tener procesos de ingeniería realmente excelentes en nuestros propios proyectos, de modo que podamos estar extremadamente seguros de la confiabilidad y funcionalidad de las cosas que introducimos en los flujos de trabajo de los desarrolladores.

DR: Al ultimate del día, ¿qué considera una «victoria»? Como mides el exito?
ALASKA: ¿Hay menos preocupaciones de seguridad este mes que el mes pasado? ¿Están los ingenieros de hoy contentos o molestos con los procesos que les imponemos?

The Edge es el hogar de Dark Reading through para características, datos de amenazas y perspectivas detalladas sobre ciberseguridad. Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia authentic