Anteriormente hablé extensamente sobre la maduración de la ciberseguridad y el paso de la seguridad basada en promesas a la basada en evidencia . En este artículo, ampliaré una de las tendencias relacionadas con esta transformación, a saber, el auge de la ingeniería de seguridad.

Pasar de la seguridad basada en promesas a la basada en evidencia y la evolución de TI

Cuando hablo de la maduración de la ciberseguridad me refiero en gran medida a cambiar la forma en que nos acercamos a hacerlo. Hasta hace muy poco, pensábamos en ello como una función y asumíamos que la seguridad es un problema de herramientas: si compra el producto de seguridad "adecuado" de "próxima generación" de un proveedor líder, estará "seguro".

Ahora, después de muchos años de ver cómo este enfoque no cumplió su promesa, comenzamos a comprender que la seguridad es un proceso, no una función. Estamos desarrollando una creencia sistémica de que debemos volver a lo básico: recopilar datos de seguridad en un solo lugar, comprender lo que sucede en nuestro entorno, aprender qué constituyen las prácticas comerciales normales en nuestra organización y qué puede ser un signo de compromiso, identificar cómo para detectar comportamientos maliciosos y responder adecuadamente. En lugar de obtener un widget que, cuando está habilitado, activa un escudo protector impenetrable, los equipos de seguridad maduros miran la seguridad a través de los lentes de las capas y los trabajos por realizar.

“La mejor manera de construir una postura de seguridad es construirla sobre controles e infraestructura que se pueda observar, probar y mejorar. No se basa en promesas de proveedores que deben tomarse al pie de la letra. Esto significa que debe conocerse el conjunto exacto de actividades y comportamientos maliciosos contra los que está protegido y debe poder probarlo y demostrarlo. También significa que si puede describir algo que desea detectar y prevenir, debería poder aplicarlo unilateralmente sin la intervención del proveedor. Por ejemplo, si un ingeniero de seguridad ha leído acerca de WannaCry, debería tener la capacidad de crear su propia lógica de detección sin esperar uno o dos días hasta que su proveedor haga una nueva versión”.

Otro factor que está cambiando la forma en que se realiza la seguridad es la evolución de TI que hemos presenciado durante la última década. Hubo un tiempo en que la experiencia en TI era suficiente para comenzar como profesional de la seguridad, ya que proporcionaría una comprensión básica de cómo funcionaban los diferentes elementos de la infraestructura, interactuaban entre sí y qué se necesitaba para protegerlos.

La automatización de la TI y el auge de la nube están abstrayendo mucho de lo que sucede en segundo plano, lo que dificulta el desarrollo de modelos mentales en torno a la infraestructura de TI y la comprensión de cómo protegerla. Para tener éxito en la seguridad actual, es necesario comprender la infraestructura local, varios componentes de la infraestructura de la nube, así como la infraestructura como código y las canalizaciones de DevOps, por nombrar algunos. A medida que la TI se vuelve más compleja, aumentan los requisitos para las personas a cargo de mantener, administrar y dar sentido a esta complejidad.

Otros factores que aceleran el cambio en la forma en que hacemos seguridad incluyen:

- Débil correlación entre resultados y gasto en seguridad,

- Negocios que exigen resultados medibles,

- La creciente complejidad de la seguridad y los entornos de los clientes,

- Proliferación de herramientas de seguridad,

- Madurez creciente de los profesionales de la seguridad,

- Aumento de las primas de seguros,

- Surgimiento de la nueva generación de proveedores de servicios,

- Aparición del ecosistema de proveedores de apoyo,

- Establecimiento de marcos de seguridad, y

- Apoyo al inversor de seguridad basada en evidencia.

La ciberseguridad del futuro se parecerá mucho a la ingeniería de software

Ver la ingeniería de software como un modelo para la ciberseguridad

La ciberseguridad se originó en los círculos de piratería, entre personas con inclinaciones técnicas curiosas sobre productos y herramientas de ingeniería inversa, retoques e irrumpir en lo que se consideraba indescifrable. Luego, varios proveedores de seguridad entraron para prometer seguridad y dijeron "lo alertaremos cuando suceda algo malo, solo tenga a alguien que verifique las alertas". Asombrados por la perspectiva de tal simplicidad, comenzamos a contratar analistas de seguridad para monitorear las alertas. Hoy, más o menos una década después, estamos viendo que tenemos que volver a lo básico. Esta toma es, obviamente, una simplificación excesiva, pero la verdad es que necesitamos que los piratas informáticos vuelvan a la industria. Lo cierto es que la ciberseguridad del futuro se va a parecer mucho a la ingeniería de software.

El desarrollo de software nos ofrece un gran modelo: los analistas comerciales y los gerentes de productos operan entre el negocio y la tecnología: hablan con los clientes, comprenden y evalúan los requisitos comerciales, los traducen en requisitos técnicos y priorizan estos requisitos para el desarrollo. A menudo escucho cómo se culpa a los equipos de seguridad por no hablar con los clientes y no entender lo suficiente el negocio. Si bien el sentimiento es justo, creo que las personas que hacen esas declaraciones no entienden el punto: criticar a los profesionales de seguridad técnica por no entender el negocio es similar a criticar a los ingenieros de back-end por no ser buenos para hacer entrevistas con los usuarios. La verdad es simple: si los ingenieros de back-end quisieran hacer entrevistas con los usuarios, no habrían elegido back-end y se habrían convertido en diseñadores de UX.

Necesitamos equipos de seguridad para comprender mejor el negocio, de eso no hay duda. Pero no podemos resolver el problema enviando a todos los miembros de TI y seguridad para que comiencen a entrevistar a los empleados de toda la empresa (aunque debemos fomentar la creación de relaciones). En su lugar, necesitamos el equivalente de analistas de negocios y gerentes de productos en seguridad para cerrar la brecha .

Principios de ingeniería de software para ciberseguridad

La ingeniería de software ofrece un gran conjunto de herramientas, conceptos, principios y modelos mentales que comparten la ciberseguridad del mañana.

En primer lugar, la seguridad del mañana será la seguridad como código.

Ahora que tenemos todo como código (políticas como código, infraestructura como código, privacidad como código, detecciones como código, etc.), podemos implementar, rastrear y probar los cambios en la postura de seguridad de la organización y revertirlas según sea necesario. Esto, a su vez, significa un enfoque que se puede probar y validar, lo que solidifica aún más el punto sobre la seguridad basada en evidencia. De manera similar a como funciona en la ingeniería de software, ahora puede ejecutar pruebas de seguridad automatizadas para ver cómo se comportará su sistema y contratar a una persona de control de calidad (piense en un probador de penetración) para ir más allá de los autómatas y buscar casos extremos que no estén cubiertos por la automatización. .

En segundo lugar, la ciberseguridad del futuro se basará en el monitoreo continuo, la implementación continua y las iteraciones frecuentes. La postura de seguridad de una organización no es estática, cambia cada segundo y la velocidad con la que cambia se ha acelerado con el surgimiento de la nube. Segundos después de que se implemente la nueva cobertura de detección y respuesta, el entorno de una organización habría cambiado con cientos de máquinas virtuales que se activan en la nube y decenas de nuevas aplicaciones SaaS instaladas en los puntos finales, por nombrar algunas. La evaluación y la cobertura de la seguridad no pueden permanecer estáticas: deben evolucionar a medida que evoluciona la propia organización. La seguridad, por lo tanto, es un proceso, no una característica: un proceso basado en la evaluación continua y el refinamiento continuo de la postura de seguridad de la organización.

En tercer lugar, la industria del mañana tendrá que hacer las cosas a escala, dando prioridad a las API. Atrás quedaron los días en que los equipos de seguridad tenían que iniciar sesión en decenas de herramientas para ajustar manualmente algunas configuraciones y, más aún, implementar manualmente soluciones de seguridad. Todo tiene que hacerse a escala de máquina, a través de la API.

En cuarto lugar, la ciberseguridad hará que el mundo de las herramientas comerciales coexista y se integre estrechamente con el mundo del código abierto. Si bien este ha sido el caso de la ingeniería de software durante un tiempo con todas las herramientas comerciales de ingeniería de software que aprovechan las bibliotecas y los componentes de código abierto, en ciberseguridad, el código abierto a menudo se ve por separado del mercado de proveedores. Previamente analicé en profundidad el papel del código abierto en la ciberseguridad, veo que este papel crece a medida que la industria madura. Los proveedores de ciberseguridad no podrán salirse con la suya simplemente creando versiones comerciales de las herramientas de código abierto; necesitarán construir sobre la base y agregar valor real más allá de hacer una declaración de que "no somos de código abierto" y mostrar su certificado de cumplimiento de SOC 2.

Adoptar un enfoque de ingeniería para la seguridad significa centrarse en mejorar los procesos para la entrega continua de defensa en lugar de marcar las casillas de cumplimiento. Permite a los equipos de seguridad ofrecer soluciones técnicas y crear herramientas escalables antes de recomendar la contratación de más personas, lo que, a su vez, les permite lograr más con menos. Todos estos factores combinados hacen que el enfoque de seguridad basado en evidencia que he discutido en profundidad antes sea inevitable; ya no es la cuestión de si, es una cuestión de cuándo (respuesta: ya está sucediendo).

Lugar de seguridad en el ciclo de vida del producto

Cuando pensamos en la seguridad, una de las primeras preguntas que nos vienen a la mente es "¿a qué parte del ciclo de vida del desarrollo de software pertenece?". Si bien es una pregunta válida, enfocarse solo en el ciclo de vida del desarrollo de software crea puntos brillantes sobre lo que sucede con el software en la naturaleza. Para analizar adecuadamente el papel del enfoque de ingeniería en la ciberseguridad, es imperativo considerar el ciclo de vida del producto como un todo, lo que incluye cómo se construye el software y qué sucede después de que comienza a usarse en producción.

Históricamente, la seguridad estaba aislada del equipo de desarrollo que creaba el producto y, como resultado, se consideraba el último paso para garantizar el "cumplimiento" antes del lanzamiento. Por supuesto, la seguridad no era la única parte del ciclo de vida de desarrollo de software (SDLC) que existía como un silo; también lo eran la gestión de productos (PM), el diseño, la ingeniería (a menudo divididos en front-end y back-end) y control de calidad (QA), por nombrar algunos.

Antes de la adopción de Agile, que instituyó la idea de equipos multifuncionales, el desarrollo de software se veía más o menos de la siguiente manera:

1. Un gerente de producto escribiría los requisitos y los enviaría a los diseñadores.
2. Los diseñadores crearían maquetas y las enviarían al equipo de desarrollo.
3. Los ingenieros de back-end completarían su parte del trabajo y enviarían la parte restante al equipo de front-end
4. Luego, el producto terminado se envió a control de calidad para su revisión.

Como las personas adecuadas no participaron en el paso correcto, este enfoque tradicional, llamado cascada, resultó en una gran cantidad de desperdicio, ineficiencias, reelaboración y malas decisiones. Agile con sus marcos Scrum y Kanban , condujo a iteraciones cortas y lanzamiento frecuente del código y, lo que es más importante, creó equipos de productos multifuncionales donde un PM, un diseñador, ingenieros de software y QA trabajarían juntos. En términos prácticos, significaba que los ingenieros de software y el control de calidad brindarían retroalimentación sobre los requisitos y diseños antes de que se consideraran listos para el desarrollo, y los PM/control de calidad brindarían su opinión a medida que se creaba el producto, lo que reduce la necesidad de descartar el código más adelante. y rehacer lo que ya estaba “hecho”.

Agile no resolvió todos los problemas. En particular, cuando surgió DevOps, los ingenieros de DevOps se encontrarían desprovistos de cualquier contexto sobre lo que estaban haciendo los equipos de productos, lo que hacía que su trabajo fuera reactivo y difícil de realizar. Eventualmente, las mejores prácticas de diseño organizacional se pusieron al día, y recientemente, en 2019, Manuel Pais y Matthew Skelton publicaron lo que, en mi opinión, es la guía más impactante sobre el diseño de equipos de tecnología : Team Topologies: Organizing Business and Technology Teams for Fast Flow . En su libro, Manuel y Matthew revisan los desafíos comunes del diseño organizacional, comparten las mejores prácticas sobre patrones e interacciones de equipos exitosos y recomiendan formas de optimizar los flujos de valor para las empresas de tecnología.

Hasta hace poco, la seguridad estaba atrasada al convertirse en parte de la organización de desarrollo, existiendo como un puesto de control aislado que, en el mejor de los casos, da luz verde a los lanzamientos y asigna nuevos tickets a los equipos de desarrollo, comúnmente marcados como "prioridad más alta". ”. Si bien ese sigue siendo un patrón observado en muchas organizaciones, el enfoque de la seguridad ha comenzado a cambiar en los últimos años. Estamos viendo el crecimiento de DevSecOps como la respuesta de seguridad a DevOps y, a medida que la seguridad se integra en las canalizaciones de CI/CD, su función está cambiando de cumplimiento a entrega de defensa. En lo que se refiere al desarrollo de nuevos productos, la seguridad está empezando a parecerse a la ingeniería de software.

De cara al futuro, es probable que sigamos viendo a los equipos de seguridad operar como unidades independientes dentro de sus organizaciones. Sin embargo, cada vez más vulnerabilidades específicas de la aplicación serán manejadas por aquellos que crean el producto y tienen más contexto sobre el código: ingenieros de software. Los equipos de seguridad actuarán como consultores de los equipos de desarrollo de productos, un papel similar al que desempeñan actualmente los ingenieros de confiabilidad de plataformas y sitios.

Mentalidad de ingeniería para la infraestructura y las operaciones de seguridad

Si bien generalmente es fácil imaginar cómo sería una mentalidad de ingeniería para la seguridad cuando hablamos de desarrollo de software, puede ser mucho más difícil de hacer cuando se observa la infraestructura y las operaciones de seguridad, cosas que suceden día a día, después, y fuera del desarrollo de software. Esto se debe en gran parte a que la seguridad de las aplicaciones es parte del ciclo de vida del desarrollo de software, y las nuevas empresas nativas de la nube financiadas con capital de riesgo han estado buscando activamente formas de proteger su código y hacerlo de una manera escalable.

Comparativamente, se ha visto poco discurso acerca de traer una mentalidad, enfoques y marcos de trabajo de ingeniería a las operaciones de seguridad, detección y respuesta, manejo de incidentes, análisis forense digital y otras áreas de seguridad. Estos componentes vitales de los procesos de seguridad cibernética de una empresa se han visto como partes internas que pueden hacer bien su trabajo siempre que tengan "los productos correctos" implementados en la red y algunas personas para monitorear estos productos. Lo que es más importante, los equipos de seguridad han estado constantemente desprovistos de recursos y consumidos por hacer frente a los últimos incendios, lo que les impide concentrarse en construir defensas de manera proactiva.

No hace falta decir que este enfoque ha demostrado ser limitante y, a menudo, perjudicial para la postura de seguridad de la organización. Si bien no tengo la evidencia para respaldar esta afirmación, especularía que la mayoría (si no todas) las empresas que aparecen en las noticias como que sufrieron una brecha en los últimos años, tenían las últimas y mejores herramientas implementadas en sus ambiente. El hecho de que estas herramientas no protegieran a las empresas de los incidentes de seguridad de ninguna manera sugiere que estén haciendo un mal trabajo (más bien al contrario). En cambio, creo que estos eventos resaltan que ningún producto es infalible a pesar de lo que pueda sugerir el marketing del proveedor, y para defender nuestros negocios y nuestra gente, tenemos que cambiar la forma en que abordamos la seguridad.

Adoptar una mentalidad de ingeniería para la seguridad significa varias cosas, entre ellas:

• Aceptar que las herramientas son solo herramientas y mirar más allá de la selección de proveedores a los fundamentos de la ciberseguridad como área de práctica. Esto significa hacer preguntas como “¿Qué debo hacer para asegurar mi organización? ¿Cuáles son los riesgos a los que me estoy enfrentando? ¿Qué comportamientos maliciosos pueden ocurrir en mi entorno? ¿Cómo los estoy detectando? ¿Cómo responderé cuando se detecten?”, en lugar de “¿Qué herramienta debo comprar para asegurar mi organización?”
• Armadas con esta comprensión, las empresas deben poner en práctica este enfoque, asegurándose de tener una visibilidad completa de su entorno ("panel de vidrio único"), de lo que están detectando y cómo lo están haciendo (saber qué detecciones funcionan en su entorno , qué detectan exactamente y cómo lo detectan), junto con la capacidad de probar sus defensas de forma reproducible.
• Darse cuenta de que muchos componentes de las operaciones de seguridad pueden y deben automatizarse y buscar formas de crear formas escalables para brindar defensa a la organización. En la práctica, esto significa adoptar detecciones como código, infraestructura como código y otros enfoques que han demostrado funcionar y escalar en otras áreas de la tecnología. Cuando un equipo detecta nuevas vulnerabilidades y comportamientos maliciosos, debe tener las herramientas para responder a ellos de una manera que elimine la necesidad de aplicar manualmente la misma respuesta a la misma vulnerabilidad mañana.

Históricamente, la mayor parte del conocimiento sobre seguridad residía en las cabezas de profesionales experimentados que “han estado allí, han hecho eso”. A medida que la industria madura, debemos buscar formas de codificar este conocimiento y hacerlo compartible, comprobable y accesible para su uso y mejora para organizaciones de todo el mundo. La ciberseguridad siempre será un arte, ya que se trata de un adversario creativo e inteligente. Sin embargo, también debe convertirse en una ciencia si queremos seguir aumentando nuestra base de conocimientos y hacer que las defensas cibernéticas sean accesibles para las organizaciones que no pueden permitirse contratar "lo mejor de lo mejor" en el campo. Adoptar el enfoque de ingeniería basado en la ciencia para la seguridad permitirá a los equipos de seguridad construir sistemas y procesos para hacer su trabajo de manera consistente.

El auge de la ingeniería de seguridad y cómo está cambiando la ciberseguridad del mañana

La evolución de la ingeniería de detección y el surgimiento de la ingeniería de detección como servicio

En los últimos años, se ha puesto mucho énfasis en la transparencia en la detección de amenazas. El problema ha atraído la atención de los profesionales de la seguridad, los fundadores de empresas emergentes y los analistas de la industria, por nombrar algunos. En 2022, dos exanalistas de Gartner, Anton Chuvakin y Oliver Rochford, escribieron un miniartículo titulado “Sobre la confianza y la transparencia en la detección”, que comienza de la siguiente manera: “Cuando detectamos amenazas, esperamos saber qué estamos detectando. Suena dolorosamente obvio, ¿verdad? Pero nos queda muy claro que a lo largo de toda la historia de la industria de la seguridad no siempre ha sido así. Algunos de nosotros recordamos los primeros días de la red. Los sistemas de detección de intrusos IDS se entregaban sin que los clientes pudieran ver cómo funcionaban las detecciones. El mercado habló, y estos vendedores están todos muertos y enterrados por Snort y sus descendientes, quienes abrieron sus firmas de detección para revisión y modificación”. La publicación del blog es una gran lectura para cualquier persona interesada en el tema.

El entorno de cada organización es único, y la singularidad solo aumenta con el crecimiento de SaaS y la aparición de herramientas especializadas para casi todo. Cada departamento de la organización tiene decenas de herramientas que utiliza para administrar su trabajo (imagine solo la cantidad de aplicaciones diseñadas para reemplazar el uso de hojas de cálculo solo para los equipos de marketing, recursos humanos, finanzas, productos y operaciones). Además de eso, casi todas las empresas que logran un cierto nivel de crecimiento desarrollan sus propias aplicaciones internas para ahorrar en los casos de uso exclusivos de sus operaciones, modelo comercial o estrategia de lanzamiento al mercado.

La singularidad del entorno de cada organización significa que tanto la forma en que los atacantes lograrían ingresar a cada organización como la forma en que los defensores podrían detectar comportamientos maliciosos en ese entorno serían diferentes. En términos prácticos, para que los equipos de seguridad resuelvan el problema de detectar algo único en el entorno de su organización, deberían crear una lógica de detección para ese entorno específico.

Los proveedores de seguridad que prometen una cobertura general para todos son una excelente capa básica (al igual que el antivirus), pero no son suficientes para las empresas que tienen mucho que perder.

La ingeniería de detección ha evolucionado mucho en los últimos 10 años, como lo atestiguan las propias personas que lo han estado haciendo durante una década . En el artículo al que se hace referencia anteriormente, Zack Allen, director de investigación de seguridad en Datadog, describe cómo el enfoque "cuanto más, mejor" para crear contenido de detección se ha convertido en una comprensión madura de que necesitamos contenido de detección completo y de alta calidad, no solo "más detecciones". ". Los ingenieros de detecciones que solían ser vistos como "magos" que "bajan de su torre y predican al mundo sus últimos hallazgos, presentes en Blackhat y DEFCON" ahora son uno de los muchos tipos de ingenieros de seguridad.

Hablando de ingeniería de detección, Zack concluye:

“No puede escribir detecciones para su producto de seguridad de red si no tiene expertos en seguridad de red. Esto es lo mismo para las detecciones basadas en el punto final, la nube, la aplicación y el host. Es como tener un grupo de científicos de datos que construyen un modelo de aprendizaje automático para detectar el asma en los pacientes. Sin embargo, se olvidaron de llamar a un médico para que les mostrara cómo los pacientes con neumonía le darían falsos positivos al modelo. Necesitas a los expertos en la materia. Esto no ha cambiado en la industria, ni debería. Lo que ha cambiado es que estos expertos necesitan una base sólida en los principios de ingeniería de software. No puede escalar todas esas detecciones e implementarlas en un entorno moderno, administrar sprints (sí, esto es ingeniería de software :)) o escribir pruebas unitarias, de integración y de regresión sin muchos cuerpos o mucha automatización. Puedo decir con certeza que mi jefe preferiría escuchar que puedo escalar el problema con el software que con la contratación de más personas”.

Veo dos señales de que la ingeniería de detección se ha convertido en una profesión dedicada y bien definida: el número creciente de eventos como DEATHCon (Conferencia de Ingeniería de Detección y Caza de Amenazas), charlas y capacitaciones en Black Hat, BSides y otras reuniones de profesionales, así como los inicios de la definición de las etapas de madurez por las que atraviesan las organizaciones al momento de implementarlo. La Matriz de Madurez de Ingeniería de Detección de Kyle Bailey es el mejor intento de medir las capacidades y la madurez de la función en todas las organizaciones.

A medida que más y más organizaciones se dan cuenta de que la lógica de detección no es igual para todos, y es poco probable que los proveedores de seguridad puedan cumplir su promesa de "mantener a todos a salvo", estamos comenzando a ver nuevas empresas de ciberseguridad que se especializan en la detección de edificios. contenido. En lugar de simplemente activar alertas, estas empresas hacen que el contenido de la regla en sí sea visible y editable, lo que permite a los equipos de seguridad comprender qué se está detectando exactamente en su entorno, cómo se está detectando exactamente y qué guías o alertas se activarán cuando se produzca. es detectado. Dos ejemplos notables de nuevas empresas en este espacio son SOC Prime y SnapAttack, que admiten el lenguaje estándar de facto para escribir contenido de detección: Sigma. En lugar de prometer una cobertura completa, estos proveedores brindan a las empresas la capacidad de acceder a la cobertura de seguridad de una manera totalmente transparente y de pago por uso.

Las organizaciones no solo pueden comprar cobertura de detección genérica de proveedores que se especializan en ingeniería de detección, sino que ahora pueden hacer que sus proveedores de servicios de seguridad construyan la lógica de alertas adaptada a su entorno. Si bien esto no es algo que ofrecen todos los proveedores en la actualidad, creo que es hacia donde se dirige la industria a medida que las consultorías de seguridad y las empresas de detección y respuesta administradas buscan agregar más valor más allá de la selección de proveedores y el monitoreo de alertas. Pronto, la ingeniería de detección como servicio se convertirá en un estándar para los proveedores de servicios de seguridad.

En particular, el cambio en las expectativas de los clientes también está cambiando la forma en que operan los proveedores de seguridad, como la detección y respuesta de punto final (EDR) y la detección y respuesta extendida (XDR). Después de haber comenzado a menudo como "cajas negras" que ejecutan una lógica de detección genérica creada internamente en todos sus clientes, ahora también ofrecen la posibilidad de que los clientes escriban sus propias detecciones en la parte superior. Los proveedores más nuevos, como LimaCharlie, donde dirijo el producto, Panther y una categoría completamente nueva de los llamados Open XDR, también ofrecen una visibilidad completa de la cobertura de seguridad de la organización (no solo las reglas personalizadas, sino todas las detecciones que se ejecutan en la organización).

La creciente importancia de la ingeniería de seguridad

Uso la ingeniería de detección como ejemplo; estamos viendo un gran impulso hacia la ingeniería en todas las áreas de seguridad. Con la infraestructura como código, la administración de la infraestructura ahora es propiedad de ingeniería, no de TI. Por lo tanto, las habilidades de ingeniería de software se están convirtiendo en un requisito previo para la seguridad.

Con el auge de la nube, los principios y prácticas de la ingeniería de software sustentan ahora cómo se aprovisiona la infraestructura, cómo se aplican las políticas y configuraciones de seguridad, cómo se prueba e interroga la postura de seguridad de la empresa, cómo se implementan y rastrean los cambios en las configuraciones de seguridad, etc. . Si bien los ingenieros de DevOps están a cargo de aprovisionar y administrar la infraestructura, los ingenieros de seguridad que combinan un sólido conocimiento de ingeniería con una comprensión profunda de la seguridad son ideales para protegerla.

La mayoría de los profesionales de ciberseguridad de hoy desarrollaron sus habilidades en TI: diseñando arquitecturas de red, aprovisionando firewalls y administrando políticas de firewall, y otras tareas críticas para mantener la TI en la empresa. Desafortunadamente, muchas de las personas a cargo de la seguridad solo tienen la comprensión más básica de la ingeniería de software, lo que les impide desarrollar las habilidades que necesitan en un mundo donde todo (infraestructura, políticas, detecciones, etc.) existe como código. Es natural que cuando la infraestructura subyacente esté codificada, los profesionales de la seguridad necesiten aprender a codificar. Lo mismo ocurre con la automatización y el uso de API: dado que la gran mayoría de las tareas técnicas ahora se realizan a escala a través de API (incluido el trabajo que antes se realizaba manualmente dentro de los propios equipos de seguridad), necesitamos personas que entiendan cómo diseñar, usar y desmantelar las API de manera segura.

Se espera que los equipos de ingeniería de seguridad vayan más allá de los controles operativos y desarrollen soluciones de ingeniería para los problemas de seguridad. A medida que más y más organizaciones se dan cuenta de que las herramientas de seguridad listas para usar no abordan la singularidad de sus necesidades y entornos, aquellas que tienen los niveles adecuados de recursos y soporte para tomar en serio el fortalecimiento de su postura de seguridad, comienzan a ir más allá de la configuración comercial. productos Si bien para algunos casos de uso, una herramienta comprada a un proveedor de seguridad puede ser adecuada para implementarla tal cual, la mayoría de las veces necesita algunos ajustes para adaptarse a las necesidades únicas de una organización. Sin embargo, vemos una comprensión cada vez mayor, especialmente entre las grandes empresas que manejan una gran cantidad de datos y las empresas nativas de la nube, de que las herramientas comerciales no pueden abordar la multitud de necesidades y requisitos de seguridad. Estas empresas están empezando a construir internamente algunos elementos de su pila de seguridad, delegando el diseño y desarrollo de estas soluciones a arquitectos de seguridad e ingenieros de seguridad internos.

Tom Tovar de Appdome sugirió en su reciente podcast que podemos clasificar las organizaciones de seguridad en tres categorías:

1. Equipos de seguridad tradicionales, compuestos por profesionales de seguridad técnicamente sólidos con un conocimiento profundo de la seguridad y el cumplimiento, y las mejores prácticas para ambos.
2. Equipos de seguridad avanzados que a menudo tienen investigadores de seguridad y arquitectos de seguridad encargados de diseñar sistemas, evaluar productos, realizar pruebas de penetración, etc.
3. Organizaciones de ciberseguridad e ingeniería que tienen talento de ingeniería "incondicional" capaz de construir y entregar soluciones de seguridad para organizaciones modernas

Veo estas categorías no como diferentes etapas de madurez, sino como una evolución en términos de necesidades organizacionales. Las empresas nativas de la nube están comenzando a crear equipos de ingeniería de seguridad diseñados para trabajar en estrecha colaboración con DevOps, ingeniería de software y desarrollo de productos. Con eso, muchos de los elementos que tradicionalmente serían propiedad de los equipos de seguridad y TI, ahora son propiedad de los equipos de ingeniería de seguridad y DevOps. Este modelo que se basa en constructores (talentos de ingeniería capaces de crear soluciones de seguridad) no es necesario para todas las organizaciones. Sin embargo, a medida que más y más empresas comienzan con la nube primero desde el primer día, a medida que sus entornos se vuelven más exclusivos con la proliferación de herramientas SaaS y a medida que más equipos de seguridad se dan cuenta del valor de la seguridad adaptada a sus necesidades, veremos una enorme cambio hacia la ingeniería de seguridad.

Al momento de escribir este artículo, vemos que las mejores prácticas para el diseño organizacional no se han puesto al día con el auge de la ingeniería de seguridad. En términos prácticos, significa que, si bien los equipos de ingeniería de seguridad tienen sus propias herramientas y son responsables de administrarlas, parece haber muchos conflictos en torno a la propiedad entre los ingenieros de seguridad y los ingenieros de software/DevOps, así como entre los equipos de seguridad operativa. Es justo decir que a partir de hoy, en cada organización que tiene la suerte de tener un equipo de ingeniería de seguridad, la forma de ese equipo se ve ligeramente diferente. Los conflictos organizacionales y las áreas poco claras de propiedad son pasos naturales en la formación de cualquier nueva disciplina, por lo que lo que estamos viendo es orgánico y esperado.

La naturaleza cambiante del rol de analista de seguridad

A medida que la ciberseguridad se convierte en código, será cada vez más difícil para aquellos que no codifican. Me refiero al rol cambiante de los analistas de seguridad.

Los analistas de seguridad, tradicionalmente clasificados en Nivel 1 (especialista en clasificación), Nivel 2 (respondedor de incidentes) y Nivel 3 (analista experto), desempeñan un papel importante en un equipo del centro de operaciones de seguridad (SOC). Con los avances recientes en la automatización, la forma de este rol ha comenzado a cambiar.

En primer lugar, a medida que los equipos de seguridad buscan formas de mejorar la eficiencia y la productividad, cada vez más procesos y procedimientos en un SOC que solían ser manuales se están automatizando. En segundo lugar, el auge de la inteligencia artificial (IA) promete eliminar la necesidad de clasificar manualmente miles de alertas, posiblemente uno de los mayores puntos débiles que experimentan los equipos de seguridad. A día de hoy, la IA aún no ha cumplido su promesa de automatizar la seguridad, pero finalmente sucederá. Probablemente antes de lo que nos gustaría imaginar, estamos obligados a ver una batalla de IA con adversarios entrenando sus propios modelos y defensa: los suyos. Dejando a un lado las imágenes futuristas, los analistas de SOC deberán adaptarse a la forma cambiante de la seguridad.

Debido a los dos factores descritos anteriormente, los analistas de SOC (especialmente los conocidos tradicionalmente como "Nivel 1") deben comenzar a aprender nuevas habilidades. La habilidad técnica más apremiante es la codificación, y los analistas lo entienden, como lo ilustra la encuesta Voice of the SOC Analyst encargada por Tines en 2022.

Hay suficientes alarmistas en la industria que sugieren que el futuro de los analistas es sombrío, pero yo lo veo diferente. El rol no va a desaparecer, pero su forma y alcance van a cambiar. En el pasado, ser analista consistía en gran medida en saber cómo utilizar productos de seguridad específicos. Ahora la seguridad empieza a ser vista no como un problema de herramientas sino como un problema de enfoque. Además, las herramientas de seguridad se están generalizando y estandarizando para que todas funcionen de manera similar: si un analista ha usado un EDR, es probable que no necesite mucho tiempo para aprender otro. Qué productos exactos usó un analista en el pasado será menos importante que su comprensión de los fundamentos de seguridad. Los analistas que buscan mantenerse relevantes a medida que la industria madura deberán volverse más técnicos. Si bien no todos se convertirán y deberían convertirse en ingenieros, será cada vez más importante que comprendan cómo los actores de amenazas ven el mundo y cómo se llevan a cabo los ataques.

Creo que el futuro de los analistas en seguridad será similar al futuro de los profesionales de control de calidad (QA) en el desarrollo de software. La gran mayoría de los trabajos de control de calidad ya no son manuales y requieren el uso de herramientas, lenguajes y marcos de automatización. Los que pagan más son lo que Amazon y muchas otras compañías ahora llaman "ingenieros en prueba": ingenieros de software que se enfocan en probar la funcionalidad del producto y las API. El control de calidad manual todavía existe, pero es difícil de conseguir, los roles son increíblemente competitivos y, como la oferta de trabajadores calificados supera con creces la demanda, obtienen la compensación más baja. Mechanical Turk de Amazon cambia drásticamente el juego, reduciendo aún más el costo del control de calidad. El control de calidad no murió, pero se transformó en gran medida (y, en particular, no se necesitó IA y ML avanzados para cambiarlo).

Pila de seguridad del futuro

A medida que los equipos de seguridad se vuelven más técnicos, comienzan a reconocer que ningún proveedor puede prometer "seguridad" y "protección" como característica. Tradicionalmente, la mayoría de las herramientas de seguridad comerciales abstraían las capas fundamentales de los equipos de seguridad y ofrecían una vista de alto nivel en forma de alertas e informes que resumían lo sucedido. Las organizaciones que querían visibilidad de las capas fundamentales de la infraestructura de seguridad y los datos a nivel de eventos se vieron obligadas a utilizar herramientas de código abierto o crear las herramientas desde cero.

Dado que el enfoque de DevSecOps requiere visibilidad de las capas fundamentales de seguridad, la pila de seguridad del futuro se verá muy diferente de lo que vemos hoy cuando observamos los llamados mapas de mercado de ciberseguridad. En primer lugar, veremos cada vez más soluciones neutrales que los profesionales pueden utilizar para interrogar sus sistemas, obtener una visibilidad completa de su entorno y crear una cobertura de seguridad adaptada a sus necesidades. Estas herramientas funcionarán de manera transparente y el trabajo que realizan se probará y verificará fácilmente. Es importante destacar que veremos una combinación de soluciones comerciales y de código abierto que pueden funcionar juntas para abordar los casos de uso de seguridad de la organización. En el centro de la seguridad estarán los procesos y los profesionales de la seguridad, no los “productos”, ya que las herramientas son solo eso, herramientas; es cómo se usan y para qué se usan lo que importa.

En los últimos años, hemos comenzado a ver que más y más líderes de seguridad rechazan la idea de confiar ciegamente en los proveedores: es el enfoque que promovemos en LimaCharlie, donde lidero el producto, así como uno adoptado por otras soluciones de nueva generación como SOC Prime, Panther, Prelude y, más recientemente , Interpres, por nombrar algunos.

La siguiente imagen es una lista de las empresas actuales y las herramientas de código abierto que adoptan un enfoque de ingeniería basado en evidencia para la seguridad. No pretende ser exhaustivo (hay muchas más herramientas excelentes que se ajustan a los criterios anteriores) y no es un "mapa de mercado" tradicional.

Cerrando la brecha del talento

Para contratar grandes talentos, las empresas deben cambiar la forma en que funcionan

Los equipos de seguridad que defienden a las empresas de los actores malintencionados están estresados, carecen de personal, están infravalorados y mal pagados. La realidad es que los grupos de piratería son mejores para atraer talento profundamente técnico que cualquier corporación. Les pagan libres de impuestos, y mucho más de lo que haría cualquier empresa. Ofrecen un excelente equilibrio entre el trabajo y la vida personal, la emoción de piratear y una sensación de logro. La mayoría de ellos son 100% anónimos. No es necesario acumular certificaciones sin valor y pagar unos pocos cientos de dólares cada pocos años para mantenerlas como "actualizadas", y no es necesario tratar con reclutadores, recursos humanos, capacitación básica en cumplimiento, política laboral, legal, cumplimiento, nómina y jefes exigentes. para acabar. Si esto suena como si estuviera anunciando que trabajo para el adversario, esa no es mi intención en absoluto, y la verdad es que nada de esto es nuevo para los profesionales de seguridad experimentados. Simplemente estoy demostrando que para contratar a un gran talento, el negocio necesita hacerlo mejor.

Esta publicación, junto con el hecho de que muchos de los mejores profesionales de seguridad no se sienten motivados para lidiar con la burocracia de trabajar para grandes corporaciones, pinta un panorama sombrío del mercado laboral actual.

Sería poco ético y falso sugerir que tengo una lista de soluciones rápidas y fáciles, por lo que nosotros, como industria, tenemos que encontrarlas juntos. Podemos comenzar eliminando el requisito de "5 años de experiencia" para los trabajos de nivel de entrada y construir sobre eso a medida que avanzamos, eliminando sesgos y mejorando nuestro proceso de contratación.

Hacer que los ingenieros de software se encarguen de la seguridad

Dado que todo en seguridad se está convirtiendo en código, uno de los conductos raramente discutidos para el talento en ciberseguridad podría ser la ingeniería de software. Algunos argumentan que puede ser más fácil enseñar seguridad a los ingenieros que ingeniería de software a los profesionales de la seguridad tecnológica. Si bien no soy la persona adecuada para emitir un juicio sobre la exactitud de esta declaración, he visto a suficientes ingenieros de software convertirse en profesionales de la seguridad para saber que ese camino es real.

El desafío radica en dar a conocer que la ciberseguridad es una carrera viable para los graduados en ingeniería de software, brindándoles la capacitación adecuada (agregando cursos de ciberseguridad de nivel profundo a los programas de ciencias de la computación) y diseñando trayectorias profesionales significativas para que encuentren su camino en la seguridad cibernética. Esto plantea una cuestión de compensación para muchos trabajos de seguridad cibernética de nivel de entrada que los recién graduados pueden obtener: si una persona puede obtener su primer trabajo en software que paga un 20-40% más que cualquier cosa que se le ofrezca en seguridad (si incluso puede obtener una entrevista ), la idea de hacer que los ingenieros de software se encarguen de la seguridad se desmorona.

Educar a la nueva generación de ingenieros de seguridad

Mucho se está hablando sobre la escasez de talento en ciberseguridad, y es fácil notar un mar de nuevos participantes que prometen resolver este problema. Desde bootcamps de seguridad cibernética de 6 semanas hasta cursos en línea, así como nuevos títulos universitarios y universitarios, todos quieren una parte del pastel en "educar el futuro de la seguridad". Es tentador pensar que todo lo que necesitamos es preparar a más estudiantes de secundaria y adultos para cambiar de carrera entusiasmados con la seguridad e inscribirse en estos programas, y de 3 a 5 años después estamos listos, veo que el problema es mucho más profundo.

Si observa la gran mayoría de los programas educativos, notará que sus currículos tienden a omitir el componente de ingeniería. No dediqué suficiente tiempo a recopilar los datos, por lo que mis observaciones sobre este tema son bastante anecdóticas, pero esto es lo que veo:

• La mayoría de los bootcamps son tan cortos y de tan alto nivel que no sería razonable creer que pueden proporcionar a sus graduados un conocimiento profundo de la industria. Conocí a muchos grandes profesionales de la seguridad que asistieron a bootcamps. Sin embargo, se hicieron grandes no porque asistieron a un campamento de entrenamiento, sino por lo que hicieron fuera de ellos. No sugiero que estos cursos cortos de inmersión no ofrezcan ningún valor. Para ilustrar el punto que estoy tratando de hacer, lo animo a pensar por qué hay tantos bootcamps de 4 a 8 semanas que enseñan desarrollo front-end y tan pocos entrenamientos de 4 a 8 semanas que enseñan desarrollo back-end. La respuesta es simplemente porque el desarrollo de back-end, similar a la seguridad, requiere una sólida comprensión de teorías y conceptos profundamente técnicos, y la capacidad de procesar estos conceptos e implementarlos en el código sin, a menudo, ninguna retroalimentación visual. Dejaré constancia de que no se puede enseñar eso durante el mismo tiempo que se tarda en enseñar a la gente a crear un sitio web sencillo.
• Muchos programas universitarios, especialmente a nivel de maestría, se enfocan más en escribir políticas que en desarrollar habilidades prácticas. Incluso aquellos que son más profundos y prácticos, tienden a ser lo que es la educación universitaria en su conjunto: demasiado antiguos, demasiado teóricos y demasiado superficiales. La seguridad evoluciona a diario, con nuevos exploits, nuevas vulnerabilidades, nuevos vectores de ataque y nuevas tecnologías en conjunto creadas a diario también. Los programas universitarios tienen que pasar por largas aprobaciones, rigurosas revisiones académicas y evaluaciones, tanto que cuando se aprueba un programa, habla de las noticias de hace seis meses o más. Hay algunos grandes maestros e instructores que están trabajando arduamente para mantenerse al día con la industria y enseñar a sus alumnos habilidades útiles, prácticas y actuales. Todos deberíamos estar profundamente agradecidos por su trabajo, pero vale la pena decir que estas personas no trabajan en línea con el sistema educativo en sí, sino que sortean sus limitaciones para hacer el bien a los estudiantes y la sociedad.
• Las certificaciones de ciberseguridad no reflejan las habilidades y experiencias que necesita el mercado. No pretendo disminuir la cantidad de esfuerzo que la gente pone en ellos, y no sugiero que no ofrezcan valor alguno. En cambio, lo que quiero decir es que, con muy, muy pocas excepciones, estas certificaciones ofrecen conceptos teóricos y hacen que las personas sientan que saben cómo se debe hacer la seguridad, sin brindar ninguna habilidad real para hacerlo. Si bien los atacantes profundizan en el código y buscan formas de eludir los controles, explotar vulnerabilidades y filtrar datos, parece que pensamos seriamente que podemos detenerlos enseñándoles a las personas cómo escribir políticas y aprobar exámenes de opción múltiple sobre seguridad en la nube. . Imagínate ser operado por un cirujano cardíaco con un “certificado en corazones” que no ha hecho una sola cirugía en su vida (no puedo).

Todo esto es una larga manera de decir que los mejores profesionales de la seguridad de hoy no salen de las universidades, y tampoco de lo que parece saldrán los de mañana. Las personas que se convierten en profesionales de vanguardia en ingeniería de seguridad provienen de trabajos prácticos en pruebas de penetración, militares, NSA y otras instituciones gubernamentales con fuertes componentes ofensivos. Provienen de equipos de seguridad maduros en empresas nativas de la nube que tratan la seguridad con seriedad. Son autodidactas frente a sus computadoras, en competencias CTF (capture the flag), y en eventos como Open SOC, Black Hat, DefCon, y similares.

Para dar forma al futuro de la seguridad y cerrar la brecha de talento, no podemos sentarnos y esperar que suficientes personas motivadas encuentren la manera de aprender por sí mismas las habilidades que necesitan para proteger a nuestra gente, negocios y países. La esperanza no es una estrategia, y tampoco lo son los bootcamps de 6 semanas; necesitamos construir sistemas e instituciones para cerrar la brecha técnica de ciberseguridad. La seguridad es difícil. Enseñar seguridad también es difícil, pero es necesario hacerlo. El cumplimiento y la redacción de políticas son importantes, pero por sí solos no nos ayudarán a defender nuestras redes de los atacantes: increíblemente talentosos, altamente capacitados, muy motivados y bien pagados.

Si bien necesitamos encontrar formas de hacer que los ingenieros de software se involucren en la ciberseguridad, también necesitamos profesionales de seguridad profundamente especializados para adquirir habilidades de ingeniería. Si bien no todos los profesionales de la respuesta a incidentes, el análisis forense digital y la seguridad de puntos finales se convertirán en ingenieros, la mayoría de las personas se beneficiarían de conocer los conceptos básicos del desarrollo de software y dominar lenguajes como Python. La adopción de un enfoque de ingeniería para las operaciones de seguridad nos permitirá automatizar las partes manuales de la respuesta a incidentes y construir continuamente formas escalables de asegurar el perímetro de la organización mientras dedicamos más tiempo a construir defensas de manera proactiva. Para eso, la educación en ciberseguridad debe comenzar a incluir cursos en ingeniería de software de la misma manera que los títulos de ingeniería de software y ciencias de la computación deben enseñar los conceptos básicos de seguridad.

Pensamientos finales

De hecho, no hay balas de plata que resuelvan todos nuestros problemas de seguridad, y producir más ingenieros de seguridad tampoco lo hará. Sin embargo, adoptar un enfoque de ingeniería para la seguridad puede ayudarnos a incorporar la seguridad en los productos de software desde su inicio, acelerar la maduración de la industria y preparar nuestras operaciones de seguridad para el futuro.

La escasez de talento seguramente será un obstáculo. Sin embargo, solo porque no tenemos los recursos que necesitamos, no podemos y no debemos descartar una solución viable al problema difícil. También está claro que tenemos que cambiar nuestras prácticas de contratación y reevaluar los criterios utilizados para identificar a los futuros líderes de seguridad. Obtenemos aquello para lo que optimizamos. Todos los días, los atacantes dedican incontables horas a aprender nuevas tecnologías, aplicar ingeniería inversa al software que construimos y buscar vulnerabilidades en el código. Si observamos las ofertas de trabajo de seguridad, es fácil concluir que esperamos detener al adversario aprobando pruebas de opción múltiple y obteniendo certificaciones que son habilidades muy diferentes a las necesarias para comprender cómo funciona el código y cómo defenderlo.

Estoy convencido de que el enfoque de ingeniería para la ciberseguridad es inevitable. Ya estamos comenzando a ver los signos de su crecimiento, y solo se acelerará a partir de aquí. La pregunta es: ¿qué tan rápido podremos construir la infraestructura para su desarrollo? Si la historia nos ha enseñado algo, es que el estado de la práctica de la seguridad cibernética en su conjunto lleva años de retraso con respecto a las últimas y mejores charlas dadas en DefCon, Black Hat y similares. Tendremos que ver qué eventos que alterarán la industria vendrán después.

La imagen principal de este artículo fue generada porAI Image Generator de HackerNoon a través del mensaje "ciberseguridad".