Cómo mantenerse al tanto de la seguridad en 2023

La seguridad y el rendimiento son la piedra angular de cada proyecto, sitio, aplicación y componente que desarrolle. Pero en este panorama en constante cambio, puede ser un desafío mantenerse al tanto de las mejores prácticas fundamentales, al tiempo que se innova.

En esta conversación, escuche a los mejores tecnólogos sobre cómo se mantienen al tanto de la seguridad y el rendimiento en 2023.

Altavoces:

• Ramadass Prabhakar, vicepresidente sénior y director de tecnología de WP Engine
• Lawrence Edmondson, director de tecnología de Barbarian
• Sergi Isasi, vicepresidente de productos, rendimiento de aplicaciones en Cloudflare
• Tim Nash, consultor de seguridad de WordPress en timnash.co.uk
• Jimmy Squires, CTO en space150

Transcripción:

RAMADAS: Hola a todos. Bienvenidos a la cuarta edición de Decode. Ha sido maravilloso ver el crecimiento de asistentes cada año. En los últimos años, ha habido un cambio significativo en el panorama de la seguridad en toda la industria. Hemos visto boletines de noticias regulares sobre brechas de seguridad y la seguridad es un tema frecuente en las conversaciones con clientes y desarrolladores por igual. Así que hoy hemos reunido a un fabuloso grupo de expertos de la industria apasionados por la seguridad y están aquí para responder nuestras preguntas y compartir sus aprendizajes con nosotros. Entonces, comencemos con una breve introducción a nuestros panelistas. Lawrence, hacia ti.

LAWRENCE EDMONDSON: Muchas gracias por recibirnos. Aquí Lawrence Edmondson, CTO de Barbarian. Barbarian es una agencia digital de servicio completo. Estamos ubicados en Nueva York.

RAMADAS: Gracias, Lawrence. A ti, Sergi.

SERGI ISASI: Gracias. Soy vicepresidente de productos en Cloudflare. Cloudflare, creamos productos que hacen que nuestros clientes y socios, como WPE, se conecten a Internet de manera más segura y rápida y estoy en San Francisco.

MODERADOR: Gracias, Sergi. Y Tim, hacia ti.

TIM NASH: Soy consultor de seguridad de WordPress aquí en el Reino Unido. Y básicamente me paso la vida asustando a los desarrolladores.

MODERADOR: Gracias. y jimmy

JIMMY SQUIRES: Sí, gracias. Estoy con Space 150, también una agencia digital de servicio completo fuera de Minneapolis y CTO allí.

MODERADOR: Gracias por aceptar estar en nuestro panel hoy. Así que me gustaría comenzar hablando de algo único que está haciendo hoy en seguridad dentro de su organización o dentro de sus equipos. Así que tal vez empecemos con Sergi.

SERGI ISASI: Sí, jugaré con la introducción de Tim, donde asusta a los desarrolladores. Una de las cosas que estamos tratando de hacer más en Cloudflare es brindarles a nuestros clientes más información sobre su tráfico y reducir la carga operativa. Históricamente, si quería encontrar lo que podría estar afectando su red, lo que podría estar viendo un ataque, implementaría un WAF, lo pondría en modo de registro y luego haría que un analista de seguridad mirara los registros y ver lo que detectó. Y hay muchos menos recursos para hacer eso en estos días.

Por lo tanto, nuestro enfoque para este año es brindar información a nuestros clientes sobre los ataques que vemos en ellos, incluso si no están usando el producto que evitaría ese ataque hoy. Para que puedan saber si su aplicación está siendo atacada o si en general está en buen estado. Y ese es nuestro enfoque para el resto del año, presentar todos nuestros productos de seguridad e informar a nuestros clientes lo que podría estar sucediendo o lo que realmente está sucediendo en su red y si quieren o no bloquearla.

MODERADOR: Maravilloso. Eso suena realmente muy poderoso. Tengo muchas ganas de escuchar más sobre eso. Así que Tim, ¿qué hay de ti?

TIM NASH: Así que trabajo con muchos clientes diferentes, tanto agencias como sitios web individuales más pequeños. Y hago muchas revisiones de código y revisiones de sitios. Y hasta este año, no he visto un crecimiento en el número de personas que realmente se preocupan tanto que la gente está muy contenta de recibir una revisión y simplemente hacer el trabajo que les dices que hagan. Entonces, si les das un montón de recomendaciones, simplemente las siguen. Pero luego, si vuelvo al sitio el próximo año, solo les daré otro montón de recomendaciones. Así que he visto un gran cambio en este último año de personas que realmente se preocupan lo suficiente como para hacer preguntas. Entonces, para mí, las auditorías de código se han desechado en la gran y larga aquí, la línea 6, 4, 2 de este archivo, bla, debe hacerse así.

Me deshice de todo eso y realmente comencé a enfocarme en la educación y me di cuenta de que, para ser honesto, lo que la mayoría de la gente quiere es que no se les diga, debes arreglar esta línea, pero para que te digan, así es como se arregla. cada línea que está a lo largo de allí. Entonces, para mí, el gran cambio y el gran cambio de enfoque ha sido hacia la educación. Y esto es algo que afecta a toda la industria. Creo que hay más y más gente hablando de seguridad este año que el año pasado y más y más de años anteriores.

MODERADOR: No, eso es maravilloso. Realmente me gusta ese enfoque de cambiar de darte el pez a enseñarte cómo atrapar el pez. Así que eso es realmente...

TIM NASH: Estaba tratando de evitar esa analogía a toda costa por ser un cliché.

MODERADOR: Gracias.

TIM NASH: simplemente bien hecho.

MODERADOR: Muy bien, Jimmy.

JIMMY SQUIRES: Sí, creo que hay tanto que decidí centrarme en una cosa realmente específica para hablar de esta respuesta. Y eso realmente restringe su alcance cuando se trata de tokens y acceso API. Creo que la violación del repositorio de Heroku y GitHub el año pasado fue un muy buen recordatorio de que solo tienes el control de tantas cosas. Entonces, cuando estemos trabajando con nuestros desarrolladores, recordándoles la importancia de esa política de acceso con alcance en cualquier plataforma o sistema con el que esté trabajando. Muchas veces, un desarrollador realmente quiere un acceso abierto bastante amplio al principio del desarrollo solo por facilidad. Y a veces, esas cosas que probablemente (nos da vergüenza admitir) no se ajustan al nivel que deberían tener antes de la producción. Entonces, comenzar temprano realmente considerando esos alcances de seguridad.

MODERADOR: Gracias, Jimmy. Y Lawrence, sé que también trabajas mucho con desarrolladores. Entonces, ¿qué están buscando en ese frente para eso?

LAWRENCE EDMONDSON: Sí, seguro. Solo para construir sobre lo que dijo Jimmy, seguro, ambos trabajamos en publicidad. Así que creo que vemos muchos de los mismos desafíos cuando trabajas en publicidad que cuando trabajas en un entorno de producto. Para nosotros, tocamos muchas tecnologías diferentes, muchas pilas de tecnología diferentes. Tenemos que ser técnicamente agnósticos. Entonces, lo que estamos viendo es que los consumidores se están involucrando de múltiples maneras ahora a través de los dispositivos móviles y las redes sociales. Hace algunos años, el escritorio era el medio principal para acceder a sitios y contenido. Ahora está completamente volcado. Pasó del escritorio al móvil y, ahora, a las redes sociales.

Por lo tanto, sus capas de API y sus capas de aplicación deben bloquearse de manera que tengan un poco de paranoia saludable asociada con ellas. Entonces, lo que estamos viendo es que el espectro de ataques está creciendo, por lo que buscamos constantemente nuevas formas de hacer que DevOps piense como programadores para que comprendan las posibles formas en que se pueden violar las cosas. Así que eso es un poco lo que estamos haciendo hoy.

MODERADOR: Gracias por eso. Y mencionaste cómo el vector de ataque está aumentando. Y eso es algo que tenemos aquí, en WP Engine, hemos estado analizando más sobre cómo adoptar un mecanismo de defensa en profundidad. Así que no confíes en ninguna capa para ser segura. Entonces, ¿cómo incorporas eso en la forma en que codificas y escribes software? Así que gracias por eso. Como todos ustedes hablaron sobre la tendencia cambiante que está ocurriendo allí, las brechas que ocurrieron el año pasado. Entonces, al mirar hacia 2023, ¿cuáles son algunos de los principales temas o amenazas a los que todos están prestando atención? Y tal vez, Sergi, puedas empezar con nosotros. Sí.

SERGI ISASI: Claro. Y esto va a sonar tonto porque es 2023 y voy a decir la palabra DDOS, pero sigue siendo una cosa. Y realmente ha sido un cambio interesante en los últimos nueve o 12 meses en el mundo DDOS. Volumétrico no es realmente un vector DDOS en estos días. Hay mucho menos reflexión. Y desde la perspectiva de un actor de amenazas, es más fácil lanzar un DDOS porque tiene muchas herramientas listas para usar, ¿verdad? Casi hemos vuelto a los días de script TD, pero también tiene muchos menos sistemas comprometidos para atacar. Entonces, si está tratando de hacer una reflexión, no hay mucha infraestructura administrada por alguien que no haya parcheado su sistema, por lo que puede tomar un paquete y convertirlo en 10. Eso ya no es gran cosa.

Así que se están moviendo a la capa 7. Y la capa 7 es más costosa de lanzar porque se necesita mucha CPU para hacerlo, pero también es mucho más costosa de mitigar. Entonces, si tiene algún tipo de sistema de protección DDOS, en realidad tiene que aceptar la conexión, examinarla y luego comenzar a soltarla en lugar de algo que podría soltar en una capa inferior. Lo que encontramos y mitigamos el DDOS de capa 7 más grande registrado el mes pasado. El gran tema de esos ataques son los dispositivos más potentes.

Entonces, si piensa en todas las cosas que hemos conectado en casa en estos días, el procesador de ese dispositivo es significativamente mejor que hace tres o cuatro años. Así que tu cámara hace mucho más. Por lo tanto, tiene una CPU más robusta, incluso sus enrutadores son en realidad una máquina bastante fuerte. Y cualquier compromiso con esos dispositivos puede permitir un gran, gran ataque, especialmente porque, si compromete uno, ahora compromete básicamente a todos los que están conectados.

La otra cosa de la que hablamos un poco en estos días, pero es un poco más tranquila, es que hemos pasado de dispositivos de hardware comprometidos a cuentas comprometidas en servicios en la nube. Los servicios en la nube tienen efectivamente una CPU ilimitada. Entonces, si puedo obtener acceso a varias cuentas de personas o empresas y activar lo que quiera en ese sistema en la nube, entonces puedo lanzar un ataque extremadamente grande. Y eso es lo que estamos viendo en los ataques récord. Entonces, sí, 2023, todavía DDOS, todavía una cosa, pero ahora en la capa 7 frente a las capas inferiores.

MODERADOR: Gracias. Eso da miedo, pero al mismo tiempo, creo que indica cómo continuamos mejorando nuestros protocolos de seguridad y el área de enfoque sigue creciendo. Lo sé, Lawrence, tú y yo habíamos hablado en el pasado sobre la IA como un auge y una amenaza. Me encantaría escuchar algunos de sus pensamientos sobre la IA generativa y cómo ve que realmente afectará el área superficial de seguridad en 2023.

LAWRENCE EDMONDSON: Estoy muy emocionado, muy optimista sobre la IA. Estamos en Barbarian, pero al mismo tiempo da mucho miedo. El potencial de algo como un chatGPT que se usa de manera maliciosa. Entonces, por ejemplo, podría hacer que Chat GPT comente su código. Y en realidad hace un trabajo bastante decente, dependiendo de qué idioma y qué tan desordenado sea su código, hace un trabajo bastante bueno. Creo que lo siguiente que veremos es Chat GPT, y es posible que ya esté en marcha porque todos los días, Chat GPT hace esto. Como hoy, acabo de ver que puede responder en Slack y encontrar respuestas en Slack.

Entonces, creo que lo siguiente, en términos de seguridad, en Chat GPT es hacer que Chat GPT encuentre exploits y realmente escriba el código en código malicioso para realmente explotar las debilidades que encuentra. Así que estamos viendo eso, especialmente el potencial de eso en la memoria. Entonces, los ataques de memoria no dejan una firma todo el tiempo. Entonces, los virus tradicionales y los escáneres de virus trabajan buscando firmas de un ataque. Dentro de los ataques a la memoria, estás atacando la aplicación. Estás haciendo algo como un desbordamiento de búfer. Está buscando comprometer la aplicación en tiempo de ejecución. Creo que Chat GPT está listo para hacer eso. Y creo que es solo cuestión de tiempo hasta que veamos que ocurre el primer exploit de ChatGPT a gran escala.

TIM NASH: ¿Cómo te imaginas que eso suceda realmente? Porque obviamente ChatGPT, en esencia, es solo un conjunto de solicitudes de API a un servidor. Y estás enviando una solicitud que dice, oye, genera un código malicioso. Lo está devolviendo. Quiero decir, hay mucha gente que ya está generando código malicioso. Entonces, ¿cómo haría que eso fuera peor que el código malicioso que ya existe?

LAWRENCE EDMONDSON: Así que eso es exactamente. Ya hay un gran repositorio para aprender. Entonces, ChatGPT, lo que hace, en realidad lo analiza: debe entrenar el modelo. Entonces, con el tiempo, los ingenieros entrenan al modelo para que reconozca cuando alguien dice esto, esto es realmente lo que quiere decir. Así que entiende el contexto. Así que es exactamente eso, pero de una manera diferente. Está entrenando al modelo para escribir código y lo que realmente significa. Y algunos idiomas son muy fáciles. Entonces PHP, es bastante fácil escribir código en PHP. Estos lenguajes interpretados son mucho más fáciles. Es mucho más complicado, pero en lugar de hacer algo como Java, que tiene que ser compilado, ¿sabes a lo que me refiero?

Así que creo que una manera fácil de hacerlo sería crear un modelo basado en chatGPT 3 que, de hecho, lo entrenas para que en realidad, superes las cosas de sintaxis, superes todas las cosas básicas de informática y luego lo tomas. un paso adelante y listo, OK, estos paquetes NPM tienen estas vulnerabilidades. Búsquelo y descubra una forma de… ellos tienen estas vulnerabilidades, lo siento, y busque una forma de explotar esas vulnerabilidades. Te lo garantizo, no estamos muy lejos de ver que suceda algo así.

MODERADOR: Gracias, Lawrence. Creo que es un área muy incipiente. Lo que es interesante en este espacio es que con la IA, en general, tiene ese equilibrio de para qué puede aprovecharla, ya sea para usar estas firmas para prevenir y aprender de ellas para ver cómo puede evitar que nosotros escribir código pobre o código vulnerable. Y al mismo tiempo, tal como hemos visto que la gente habla, hey, escribí mi primer complemento en cinco minutos con Chat GPT, creo que sí, se trata más de si esto comienza a permitir que las personas creen un poco de malware. ¿más rápido? Pero creo que tiene ambos aspectos.

Se trata más de cómo continúa aprovechando cualquiera de estas herramientas para mejorar en la escritura de código, pero escribiendo un código más seguro. Y lo sé, Tim, esa es un área que te apasiona. ¿Le gustaría hablar un poco más sobre cómo ve la evolución de Secure Code en 2023 y qué está haciendo en ese espacio?

TIM NASH: Bueno, quiero decir, en muchos sentidos, Chat GPT es un buen ejemplo de eso. Si estaba pensando en un vector de ataque, seré honesto, no estaba pensando en hacer un escaneo masivo, alimentándolo con muchas cosas como un mal actor. Estaba pensando en él como el desarrollador de código promedio que estaba tratando de ahorrar tiempo y estaba ingresando cosas en Chat GPT y tirándolo y no necesariamente entendiendo completamente todo el código que se está escribiendo, produciendo, no he escrito ninguna prueba para ve con eso Esto es solo algo rápido, es solo un guión rápido, todo está bien. Se pone en producción, no está bien y se quema todo.

Ahora bien, esto es exactamente lo mismo que algo que todos los desarrolladores hacen todos los días, independientemente. Chat GPT no cambia eso, pero lo habilita un poco más fácilmente. Sí da, hay menos barreras.

SERGI ISASI: Sí, así que no es lo mismo que copiar y pegar desde Stack Overflow, que creo que es a lo que te refieres, Tim, que es básicamente todo lo que hago para el código. Pero creo que es un aumento en la eficiencia seguro, tanto para positivo como para negativo. Pero sí creo que permite cambios más sutiles y una explotación más rápida de algo que la mayoría de los motores basados ​​en firmas realmente no pueden alcanzar. Así que realmente cuando estás haciendo detección, necesitas tener un sistema que diga si esto se parece a algo que he visto en el pasado, en lugar de coincidir directamente con algo que he visto en el pasado. Y eso es en realidad en el lado de la detección, probablemente también se sirve mejor con ML o AI o como quieras llamarlo.

Hemos aprendido eso con el tráfico automatizado en, ya sabes, básicamente bots. La mejor manera de aprender cómo sortean la detección basada en firmas es con ML. Pero ahora está pasando de, Sé absolutamente que esto es malo, a, bueno, es probable que esté automatizado, o que parezca una firma que he visto antes, pero no una coincidencia exacta.

MODERADOR: Maravilloso. Gracias. Gracias, Sergi y Tim por ese contexto añadido. Entonces, entre nuestros asistentes, tenemos muchos desarrolladores y agencias que están presentes aquí hoy. Y mucha gente está pensando en establecer las mejores prácticas, especialmente porque los escenarios están cambiando en términos de vectores de amenazas. Entonces, ¿cuáles son algunas de las mejores prácticas que recomendaría al crear un sitio, una aplicación o una plataforma, o simplemente cuando comienza un nuevo proyecto? Entonces, ¿cuáles son algunas de las cosas que la gente debería tener en cuenta?

SERGI ISASI: Así que puedo empezar eso. Sería más del lado operativo que del lado del desarrollo. Creo que una de las cosas que predicamos aquí es, una, asumir que algo malo sucederá. Así que se avecina una brecha, no puedes dejarte sorprender por ella. Es probable que suceda en algún momento. Y nuestra clave, entonces, primero, cree un libro de ejecución para eso. Entonces, cuando suceda, sepa a qué personas contactar y cuál será su respuesta, tanto desde la detección como la respuesta, pero también comunicándose con sus clientes si los afecta. Y en ese sentido, lo que, creo, hacemos muy bien en Cloudflare y ha sido parte de nuestra marca y creo que nos sirvió muy bien es ser sinceros, abiertos y tan comunicativos como sea posible sobre cualquier cosa. eso pasó.

La apertura ha sido clave para restablecer la confianza con los clientes cuando ocurre algo, ya sea una violación de software o algún error que haya cometido en términos de un incidente. Esconderse detrás nunca es la decisión correcta.

MODERADOR: Sí.

JIMMY SQUIRES: Creo que otra cosa también es que ahora que todos son obviamente remotos y especialmente en los equipos de desarrollo, en realidad se están tomando el tiempo al comienzo de un proyecto para hacer un pizarrón y una planificación arquitectónica. Es muy fácil sumergirse directamente en los requisitos y eliminar las historias de desarrollo, pero pasar tiempo con sus compañeros para desafiar ¿cómo podría explotarse esto? Corre a través de escenarios. Hacemos una gran cantidad de planificación de escenarios que lleva a una gran cantidad de buenas conversaciones sobre cómo queremos reforzar las diferentes partes de la aplicación.

LAWRENCE EDMONDSON: Y solo sobre eso, no sé si alguien lo sabe, pero MPM es en realidad el repositorio más grande de bibliotecas compartidas, es el repositorio más grande de bibliotecas de aplicaciones que existe, pero eso significa que también representa el mayor riesgo. Entonces, una cosa de la que somos muy conscientes cuando asumimos un nuevo proyecto si usamos NPM es asegurarnos de que estamos analizando las vulnerabilidades, que estamos bloqueando versiones que empujamos para producir, eso antes de que Estamos haciendo una actualización, nos aseguramos de que sea algo compatible, pero también muy seguro. No hay amenazas abiertas porque hemos visto muchas vulnerabilidades a través de NPM. Así que eso es sólo una cosa a tener en cuenta.

TIM NASH: Creo que lo estamos dando vueltas.

JIMMY SQUIRES: Adelante, Tim.

TIM NASH: Creo que estamos dando la vuelta a la idea de que, en realidad, la confianza se está rompiendo por completo en los ciclos de desarrollo durante años. La gente se está dando cuenta ahora. Y si eres un desarrollador de PHP que trabaja en WordPress, por ejemplo, te sientas ahí llamando acciones y filtros, pero no deberías confiar en esas acciones y filtros. Cualquier dato que ingrese, debe validarlo, debe verificarlo. Debe ser desinfectado. Pero cuando sale de la base de datos, aún no deberías confiar en él.

Aunque hayas puesto esos datos en la base de datos, no deberías confiar en los datos que salen. Si estamos pasando algo a una biblioteca de terceros, ya sea NPM, sea ese paquete de compositor o simplemente otro complemento de WordPress, inmediatamente queda bajo nuestro control, no confiamos en él nuevamente. Pero cuando vuelve, incluso si lo hemos comprobado, todavía no confiamos en él. Y si entra con esa mentalidad, como desarrollador, de que no se debe confiar en cada pieza de datos y debe aislarse completamente y debe realizar controles de seguridad en cada punto dado, obtendrá con un sistema mucho más seguro. Es posible que salga con un sistema un poco más lento. Es posible que se encuentre con un sistema un poco más frustrante y que necesite muchas más pruebas para asegurarse de que lo que está haciendo en realidad no está causando más problemas de lo que está ayudando.

MODERADOR: Sí.

TIM NASH: Agrega complicación, pero terminas con un sistema mucho más seguro. Y para la mayoría de la gente, eso es lo que quieren.

LAWRENCE EDMONDSON: Sí.

MODERADOR: Sí. Estás absolutamente en lo correcto. Se trata de no confiar en ninguna otra pieza de código que esté llegando. Y de lo que hablaron Jimmy y Sergi, es tener un plan y desde una perspectiva de arquitectura, o desde una perspectiva operativa, pero incorporar todo eso en su práctica general, ya sea como mecanismos de codificación de seguridad o tener un libro de jugadas de incidentes. Entonces, Tim, estoy muy interesado en saber más de ti: capacitas mucho, enseñas mucho en todo el mundo. ¿Cuáles son algunos errores comunes que ves cuando las personas comienzan a trabajar en proyectos, o errores que podrías haber cometido? He cometido muchos de ellos.

TIM NASH: Iba a decir que estoy bastante seguro de que soy culpable de todos los errores de los que estoy a punto de hablar. Y el más grande y el más simple es ser una buena persona. La mayoría de los desarrolladores asumen buenas intenciones. La mayoría de la gente asume que va a utilizar su aplicación tal como la escribió. Ahora, con bastante frecuencia, no escribimos documentación, por lo que el usuario no tiene idea de cómo usar la aplicación en primer lugar, pero ese es un tema aparte. Un mal actor entrará y tomará cualquier error y se irá, eso no es un error, para un mal actor, eso es una característica. Esa es una oportunidad. Está haciendo algo que el desarrollador no espera, por lo tanto, hay una ruta potencial hacia eso.

Y en general, algo que ves una y otra vez, cuando dices, mira, tienes un conjunto de pruebas unitarias. Oh, genial. Pero solo has probado las cosas positivas, el resultado que querías. No has probado lo que sucede si salimos de estos límites. Acabas de probar para asegurarte de que la cosa funciona de acuerdo con lo que quiere tu jefe. Entonces, lo que realmente tiene son pruebas de aceptación, pruebas de aceptación dudosas. Y luego todo vuelve a lo básico. Como desarrollador, está respaldado por esto, no confíes en las cosas. Y si usted es un desarrollador de WordPress en particular, WordPress en realidad tiene algunas funciones de ayuda realmente buenas para hacer todo el tipo de cosas de seguridad estándar que le pedimos a la gente que haga.

Y se trata de educarlos y aprender a usarlos. Cuando estoy haciendo revisiones de código, una y otra vez veo los mismos problemas. Y si lo veo una vez en un fragmento de código, lo veré 1000 veces en el mismo conjunto de código. Y serán cosas como, sí, bueno, solo permitimos que aparezcan cosas antiguas en la página. No nos molestamos en comprobar si tenía o no algo allí. Sí, ponemos cosas en la base de datos. Oh, mira, puede parecer una consulta SQL, puede que no.

Todo este tipo de cosas son fáciles de solucionar y ya hemos proporcionado las herramientas para solucionarlo. Y la razón por la que no los reparamos a menudo ni siquiera es que las personas no saben que no deben permitir que estas cosas sucedan, es solo que nos volvemos perezosos, hacemos las cosas rápidamente, tomamos código de Stack Overflow, estamos haciendo que Chat GPT haga cosas por nosotros, no estamos revisando las cosas. Y muchos problemas de seguridad provienen de este estado de, debo apresurarme. Debo apresurarme. Debo apresurarme, tengo que terminar esto. Voy a pasar a lo siguiente, voy a pasar a lo siguiente.

Extrañamente, para muchos desarrolladores, simplemente darles el tiempo y el espacio y decir, está bien tomarse el tiempo para verificar realmente lo que han hecho para que cuando se descomponga, y en los casos en los que yo entre en juego, Vuelvo y digo, bueno, todas estas cosas y los desarrolladores se ven avergonzados. Ellos van, sí, sabemos todo esto. Simplemente no teníamos tiempo.

Entonces, con suerte, dar a las personas más tiempo y realmente darles las herramientas, que ya tenemos particularmente dentro de WordPress. WordPress tiene un conjunto realmente brillante de funciones de ayuda para los problemas de seguridad más comunes que tendría en un complemento o tema de WordPress. Entonces, se trata solo de aprenderlos y luego invertir el tiempo para implementarlos realmente.

MODERADOR: Sí. Y creo que eso es realmente poderoso, invertir el tiempo. La mayoría de las veces, los desarrolladores saben qué se debe corregir. Así que dándoles tiempo. Así que realmente me gusta ese mensaje. Y Jimmy, sé que has incluido esto en tu propio flujo de trabajo en tu agencia. ¿Quiere hablar un poco más sobre las prácticas de flujo de trabajo seguro que implementó?

JIMMY SQUIRES: Sí, absolutamente. Y realmente, comienza simplemente con tener algo que, según Sergi, es tener un plan, en realidad tener pautas y estándares para que los siga su equipo de desarrollo. Sé que probablemente suene muy básico, pero he visto muchas organizaciones y he escuchado de muchos ingenieros que hemos contratado a lo largo de los años que no existía. No había organización en el lugar de trabajo de donde venían.

Entonces, lo que nos gusta hacer es tener un conjunto estándar de pautas, todos nuestros nuevos ingenieros deben leerlo de arriba a abajo. No es tan pesado que no es consumible. Nos gusta mantenerlo en rebajas, por lo que está todo en un repositorio. Probablemente lo abriremos en algún momento. No hay nada allí que sea realmente propietario, y luego alentamos a todos a contribuir. Esa es una pregunta para todos los ingenieros.

Entonces, incluso en nuestras pautas, haga agujeros donde podamos agregar, donde podamos ser mejores, hacer crecer eso continuamente. Pero pasar tiempo con eso, algunas de las cosas básicas como OWASP, esa es una práctica muy antigua, pero pasar por eso con su aplicación, considerando esas cosas. Es más o menos lo que dijo Tim, es realmente tomarse el tiempo y estar bien para tomarse el tiempo con eso. Quería agregar un punto extra a la conversación sobre IA. Hablando con algunos de nuestros ingenieros la semana pasada en realidad tuvo un evento. Eso es algo para lo que estamos usando Chat GPT, en realidad es una prueba unitaria. Tomando una función y explorándola de maneras interesantes, ¿cómo puede aprovechar algo como Chat GPT para escribir una prueba de unidad en la que no será el mejor autor de esa prueba de unidad, al punto de Tim? Ahí es donde creo que podemos aprovechar mucho más la IA de manera preventiva.

LAWRENCE EDMONDSON: Sí. Lo que estamos haciendo de nuestro lado, creo que las listas de verificación y tener un libro de jugadas son geniales. Usamos herramientas automatizadas como SonarQube y realmente implementamos el linting y cosas así, solo para mejorar la calidad del código con el linting, pero también usamos SonarQube para asegurarnos de que el código sea más seguro, que estamos buscando por vulnerabilidades y cosas por el estilo. Creo que es más fácil encontrar exploits en algunos idiomas que en otros, como mencioné antes, solo por la naturaleza del idioma. Y también solo ciertos marcos en los que la calidad de los codificadores que contribuyen a esa base de código generalmente, por lo general, vemos esto con el código abierto, donde es como, hay mucho copiado y pegado de desbordamiento de pila, en comparación con personas que realmente han estudiado. CS y realmente saben lo que están haciendo. Así que eso es sólo una cosa que he visto.

TIM NASH: Siento que deberíamos señalar, ciertamente para mí, que uso Stack OverFlow casi todos los días. Y entonces todos somos culpables de ello. Es bueno criticarlo, pero no creo... Quiero decir, recuerdo cuando empecé a codificar. Obtuve una revista y estaba escribiendo el código de la revista y presionando Enter. No puedo imaginar que la web funcione realmente hoy en día si todavía nos quedáramos haciendo eso y no tuviéramos Stack Overflow, o similar.

Sergi: No, es el acelerante. Y con suerte, la IA es la próxima etapa de eso. Pero sí, es un meme divertido.

MODERADOR: Gracias. Así que cambiando un poco. Hay mucho impulso en la industria en torno a las implementaciones Headless y Headless. Y también hemos visto en algunos de nuestros otros canales hoy o en otras sesiones que se habla de Headless. Entonces, cuando comenzamos a trabajar con Atlas en WP Engine, nos reunimos con muchos desarrolladores y la seguridad siempre fue un motivador clave. Entonces, ¿cómo ve la seguridad con Headless? Y lo sé, Jimmy, esta es un área en la que has hecho algunos proyectos al respecto. Nos encantaría conocer tu opinión al respecto.

JIMMY SQUIRES: Sí, trabajamos mucho en Headless. Creo que casi todos nuestros proyectos en este punto probablemente adopten un enfoque de arquitectura sin cabeza. Creo que quiero hacer un par de puntos al respecto, en lo que se refiere a la seguridad. Entonces, creo que la primera es que cuando eliges una arquitectura sin cabeza, generalmente te estás poniendo más en el campo de código abierto al principio. Y hay mucho debate, por supuesto, sobre qué es más seguro, código abierto o código cerrado. Tiendo a caer en el campo de los proyectos OSS que son más seguros por naturaleza. Así que estás eligiendo marcos como Next, WordPress, donde tienes una comunidad gigante. Y eso tiende a prestarse a una mayor seguridad a través de la exposición.

Así que creo que ese es uno. Creo que el segundo es algo así como Generación Estática. Por lo tanto, muchos sitios web y productos que se construyen no necesitan la naturaleza dinámica de un gran sistema monolítico de administración de contenido en un sentido tradicional. Puede aprovechar algo como Cloudflare y generar realmente de forma estática grandes porciones de esa aplicación, reduciendo así su huella para vectores y exposición. Así que somos grandes fans de eso. Y luego, por supuesto, también obtiene todos los beneficios de rendimiento con eso. Esos son solo un par de puntos que quería hacer sobre la arquitectura sin cabeza. Pero muchas más razones desde el punto de vista de la seguridad por las que nos gusta. Pero creo que esas son probablemente dos de las áreas más destacadas.

TIM NASH: Me gustaría retroceder y recordarle a la gente que todavía hay un sistema de administración de contenido en la parte de atrás. Y eso lo escucho muy a menudo, Headless es totalmente seguro. Es como, sí, pero esa instancia de WordPress expuesta que todavía está allí, solo porque no la estás llamando directamente desde el sitio web, sí, todavía está allí en admin.yoursite.com. Y no lo ha hecho, hay una cierta creencia de que, oh sí, bueno, ahora estamos seguros, así que no tenemos que preocuparnos por mantenerlo actualizado porque no es el sitio web. Es como, no, no, todavía necesitas todas las cosas que estabas haciendo antes y ahora también tenemos el otro lado.

Y quiero decir, Headless es un gran término que es para algo que ha existido durante mucho tiempo y está cobrando mucho impulso, pero estábamos haciendo esto desde antes de que WordPress tuviera una API REST. Estábamos enviando contenido de WordPress a cosas como Jekyll para obtener al menos un sitio estático. Y la razón original para hacerlo fue cambiar el sistema de WordPress o su sistema de administración de contenido dentro de su red. Así que podrías bloquearlo y mantenerlo alejado de la gran y aterradora red.

Ahora estamos recibiendo muchas empresas de alojamiento que ofrecen soluciones sin cabeza. And that infrastructure is now out in the cloud again. So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. Gracias. And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.