Qué ingeniero de seguridad e ingeniero de software program …


Un ingeniero de seguridad y un ingeniero de infraestructura de Salesforce comparten las lecciones aprendidas de su inversión de roles profesionales y consejos para las personas de ambos equipos.

Los equipos de ingeniería de seguridad e ingeniería de software package tienen mucho que aprender unos de otros, ya que dos empleados de Salesforce aprendieron en una «inversión de roles profesionales» que les enseñó cómo ambos equipos pueden trabajar juntos de manera más eficiente y colaborar mejor en la creación de computer software seguro.

Como parte del intercambio, el ingeniero de seguridad principal Craig Ingram se incorporó al equipo de ejecución de Salesforce. La ingeniera de infraestructura principal, Camille Mackinnon, se unió al equipo de evaluación de seguridad de la plataforma. En una sesión informativa de Black Hat el 5 de agosto, los dos compartieron historias y lecciones aprendidas.

La planificación y la priorización fueron dos grandes conclusiones del período de Ingram en el equipo de ejecución. Los ingenieros dedicaban gran parte de su tiempo a analizar prioridades en competencia y decidir en qué iban a trabajar: había nuevas funciones que tenían que desarrollar corrección de errores para mejorar la escalabilidad y el rendimiento en su plataforma. Por supuesto, la seguridad también solicitó correcciones de errores.

«Como alguien que pensaba que era bastante empático con el equilibrio que los ingenieros necesitaban tener, entre el trabajo de ingeniería en curso y las interrupciones y otros proyectos de seguridad, period otra cosa completamente distinta vivirlo», dijo en la charla. «No pudimos hacer todo a la vez. Tuvimos que dividir las cosas en piezas pequeñas y manejables».

Así es como escalan los equipos de ingeniería, explicó Ingram: dividen los proyectos en partes. Muchos utilizan objetivos y resultados clave (OKR) para determinar qué se necesita hacer y definir cuáles serán los resultados de un proyecto determinado. Es una forma mensurable de asegurar si un proyecto fue exitoso o no, así como de identificar qué proyectos podrían retrasarse, agregó.

«Este es el momento de una priorización despiadada», dijo Ingram, y es hora de que los ingenieros de seguridad digan no a las cosas que no tienen el mayor impacto o las muevan más hacia sus objetivos. Tal vez implementar la última herramienta que vio no sea tan impactante como implementar una herramienta de seguridad de la cadena de suministro que podría probar el cambio de código en los paquetes de código abierto que utilizan los ingenieros.

El concepto de «desarrollo impulsado por pruebas» (TDD) fue una forma en que notó que la seguridad y la ingeniería de program podían mejorar. Los ingenieros de software program determinan que su código es funcional escribiendo pruebas. Cuando el application pasa una prueba, hay una notion razonablemente buena de que ahora es funcional.

Como la seguridad es parte de la funcionalidad del application, dijo, el equipo puede contribuir escribiendo pruebas de program centradas en la seguridad. Por ejemplo, un buen candidato para una prueba fallida es una falla de seguridad encontrada en una evaluación. Un ingeniero sabrá que el error se ha corregido cuando se apruebe la prueba, y el código continuará viviendo en un marco de prueba para futuras pruebas. El equipo sabrá si hay una regresión porque el computer software no pasará la prueba, explicó.

Mirar hacia atrás antes de seguir adelante

Otra práctica útil fue la «retrospectiva», que el equipo de tiempo de ejecución hizo cada semana para revisar lo que completaron y / o repasar un incidente, como un tiempo de inactividad o un problema de seguridad.

«Este period un momento para tener una conversación segura sobre lo que va bien, lo que no va bien, lo que queremos seguir haciendo y lo que queremos mejorar», explicó. La plan es crear una línea de tiempo de todas las cosas que suceden y señalar lo que se puede aprender para la próxima vez.

Esto también se puede aplicar a los equipos de seguridad, que podrían programar una retrospectiva cada dos semanas. Es un buen momento para hacer preguntas como «¿Estamos teniendo un impacto?» «¿Nos estamos quedando atrás?» «¿Estamos cumpliendo con las expectativas de los clientes?» Si estas cosas siguen apareciendo en una retrospectiva, señaló, puede ser el momento de volver a priorizar los proyectos o crear un nuevo objetivo.

Las retrospectivas son irreprochables, lo que Ingram dijo que es el aspecto más importante de la práctica. Un análisis de la causa raíz del problema no significa averiguar quién hizo algo mal («no es necesariamente culpa de un individuo si falla una base de datos de producción»), sino observar qué controles faltaban que permitieron que ocurriera un problema en la primera sitio. Advirtió que los equipos pueden hacer más daño que bien si primero no establecen confianza antes de programar una retrospectiva.

Mackinnon enfatizó la importancia de escuchar a los ingenieros y solicitar comentarios de los usuarios. Los equipos de ingeniería confían en los directores de producto y los investigadores de usuarios profesionales para realizar entrevistas con los clientes y crear productos que se adapten a sus necesidades. Ella aconsejó a seguridad que hiciera lo mismo.

«Los animo a que intenten comprender las necesidades de su equipo de ingenieros», dijo. «Incluso si tiene que decir que no en algunos casos, hacer que un ingeniero realmente entienda que usted analizó su necesidad, que comprende por qué necesitan llegar más rápido y han tratado de solucionar sus problemas y ayudarlos a construir algo más seguro … contribuirá en gran medida a garantizar que es probable que se sigan sus recomendaciones «.

Si bien simplificar las cosas para los ingenieros puede generar más trabajo para los equipos de seguridad a corto plazo, dijo, significa que es más probable que los ingenieros se alineen con las prácticas de seguridad y la postura de seguridad de la organización puede mejorar en common.

Una forma en que la seguridad de la información puede involucrarse más es «desplazándose a la izquierda» o moviendo el proceso de ingeniería de seguridad para que se integre en la fase anterior del ciclo de vida del desarrollo de program. Esto puede significar aparecer en las reuniones de Scrum y aprender cómo se construye el software program una mejor comprensión de esto puede ayudar a mejorar el papel de la seguridad en el desarrollo de software package.

«Comience con los cambios pequeños», dijo Ingram. «Empiece a cambiar la forma en que hace las cosas, empiece a utilizar los principios de la ingeniería de software, empiece a cambiar la forma en que su equipo planifica. Pruebe retrospectivas. Empiece a recopilar comentarios de los usuarios de los clientes. Cuando trabaje y actúe como los equipos con los que está asociado, un proceso mucho mejor para todos «.

Contenido relacionado:

Regístrese ahora para el Black Hat United states of america totalmente digital de este año, programado para el 1 y 6 de agosto, y obtenga más información sobre el evento en el sitio world wide web de Black Hat. Haga clic para obtener detalles sobre información de la conferencia y para registrarse.

Kelly Sheridan es la editora de particular de Dim Examining, donde se enfoca en noticias y análisis de ciberseguridad. Ella es una periodista de tecnología empresarial que anteriormente reportó para InformationWeek, donde cubrió Microsoft, y Seguros y Tecnología, donde cubrió finanzas … Ver biografía completa

Lectura recomendada:

Más strategies





Enlace a la noticia unique