DE{CODE}: Mantenga sus sitios de WordPress seguros en medio de un aumento en los ataques cibernéticos globales

Únase a expertos de WP Engine y Cloudflare para esta sesión específica de seguridad sobre cómo bloquear sus sitios web. La discusión destaca las tendencias recientes de ataques cibernéticos junto con ejemplos específicos de cómo WP Engine protege sus sitios. Los desarrolladores se irán con una lista de verificación clara de los pasos a seguir para proteger sus sitios.

Diapositivas de la sesión

Transcripción de texto completo

ERIC JONES : Bienvenido a DE{CODE} y gracias por unirse a lo que promete ser una sesión de trabajo increíble. Mi nombre es Eric Jones y soy el vicepresidente de marketing corporativo aquí en WP Engine. No podría estar más emocionado de moderar esta discusión hoy entre Joe Sullivan, director de seguridad de Cloudflare, y Brent Stackhouse, vicepresidente de seguridad de WP Engine, quienes tienen décadas de experiencia en seguridad.

Nuestra discusión, Mantener seguros sus sitios de WordPress en medio de un aumento en los ataques de ciberseguridad global, no podría ser más oportuna dado que los ataques cibernéticos no solo están en aumento, sino que también están en máximos históricos. Joe, ¿por qué no empezamos contigo? Me encantaría escuchar desde una perspectiva macro amplia qué tendencias está viendo en el panorama de la seguridad cibernética.

JOE SULLIVAN : Claro. Estoy feliz de participar. Gracias por invitarme a esta conversación. Yo también estoy deseando que llegue. Creo que hay dos, supongo, megatendencias en el mundo de la seguridad en este momento. Número uno es que es mucho más importante a los ojos del mundo.

Entonces, antes de pasar al aspecto técnico y los desafíos reales que enfrentamos día tras día, vale la pena tomarse un momento para ver cuánto ha evolucionado el mundo de la seguridad desde que Brent y yo comenzamos en esta profesión, como dijiste, hace décadas.

La seguridad ya no es un equipo o un concepto que se sienta en la esquina de una organización. Es fundamental para todo lo que hacemos. Los directores ejecutivos están siendo responsabilizados. Las juntas están haciendo preguntas difíciles. Los capitalistas de riesgo no contribuirán a menos que vean el nivel correcto de inversión.

Y, lo que es más importante, nuestros clientes, consumidores y compradores comerciales de nuestros productos exigen mucho más de nosotros. Y eso, para mí, es la tendencia más importante y por qué estamos teniendo esta conversación. Es importante para todos los desarrolladores en todos los aspectos de su trabajo.

Entonces, en cuanto a lo que realmente está sucediendo en el mundo de la seguridad, no se está volviendo más fácil. Y los desafíos siguen llegando a nosotros. Si está prestando atención a los titulares, ha visto en los últimos tiempos el auge del ransomware. Da mucho miedo.

El ransomware cambió el juego en términos de seguridad porque pasó de robar algunos datos o exponer algo al mundo a cerrar su negocio. Y así, todo el concepto de la importancia de la seguridad se vio magnificado por ese riesgo, la idea de que podríamos despertarnos por la mañana y no poder encender nuestras computadoras portátiles, no hacer que nuestro sitio web funcione. Eso es realmente aterrador.

Las cosas geopolíticas también están comenzando a impactarnos a todos. La situación en Ucrania no está contenida en el mundo físico. Está fuertemente en el contexto cibernético en este momento. Y se está derramando para impactar al resto de nosotros. Entonces, los eventos geopolíticos que están sucediendo en el mundo físico tienen implicaciones técnicas para aquellos de nosotros que intentamos operar negocios que están en Internet.

Y creo que lo tercero que mencionaría desde un punto de vista técnico es que no vivimos en mundos de nuestro propio código. Vivimos en mundos que son una amalgama de software y código que se unen para representar una organización.

Y así, en seguridad, usamos el término cadena de suministro para hablar de todo ese otro código y otras aplicaciones y todo lo que se convierte en parte de nuestra identidad como empresa. Entonces, por ejemplo, cuando recientemente hubo historias sobre el compromiso de Okta, no se trataba solo de si Okta estaba comprometido. Era una cuestión de si mi empresa y todas las demás empresas que usan Okta están comprometidas.

Y a mis clientes no les importaba Okta. Se preocuparon por su uso de nosotros, y ¿qué controles teníamos implementados para mitigar el riesgo de que Okta se viera comprometida? Así que están sucediendo muchas cosas en este momento. Y es un buen momento para tener esta conversación.

ERIC JONES: Joe, solo como una pregunta de seguimiento, ¿cómo piensa acerca de la priorización de todos esos desafíos específicos que tiene y que tiene cada organización de seguridad?

JOE SULLIVAN: Seguro. Creo que esa es la última pregunta. Si tuviéramos un presupuesto ilimitado y personas ilimitadas que pudieran hacer el trabajo, podríamos hacerlo todo. Pero esa no es la realidad en ninguna organización en ninguna etapa de su desarrollo.

Así que siempre estamos en el proceso de priorización. Entonces, lo que diría es que primero debes priorizar lo básico. Es impactante que un gran porcentaje de los compromisos provengan de fallas en lo básico.

Como profesionales de la seguridad, nos encanta profundizar en ese ataque de día cero o ataque de día O y observar esta cosa realmente complicada. Pero el 90% de las veces, los compromisos provienen de correos electrónicos de phishing o de alguien que elige usar la misma contraseña que usó en un sitio web personal que se vio comprometido y no activó la autenticación multifactor.

Muchas veces, tenemos las herramientas para hacer bien lo básico, pero no nos tomamos el tiempo para implementarlas.

ERIC JONES: Sí, creo que está llegando a un punto crucial en seguridad, ¿verdad? Que es algo de lo que todos somos responsables. Es una responsabilidad compartida en toda la organización. No vive sólo dentro del equipo de seguridad. Vive con cada empleado de una empresa en particular.

Brent, volviéndote a ti, desde la perspectiva de WordPress, ¿qué es lo mismo, qué es diferente en WordPress y cuáles son algunos de los mayores puntos de vulnerabilidad que ves en el panorama?

BRENT STACKHOUSE : Gracias, Eric, y gracias por invitarme. Agradezco compartir tiempo con Joe. Sabe muchas cosas. Hemos dado la vuelta a la manzana un par de veces. Así que esto es fascinante.

WordPress en muchos sentidos: las noticias son generalmente buenas en el sentido de que WordPress Core se diferencia de todos los complementos y temas y otras cosas en el ecosistema de WordPress. WordPress Core sigue siendo robusto y resistente frente a ataques comunes.

Por lo tanto, WordPress en sí mismo es una plataforma buena, estable y sólida con la que los clientes generalmente deberían sentirse cómodos en casi cualquier contexto. El desafío está principalmente en el lado de los complementos, donde wordpress.org o esos desarrolladores principales generalmente no tienen nada que ver con la mayoría de los complementos y temas.

Y la variabilidad de la calidad del código, similar a las aplicaciones que obtienes en Play Store de Google o algo así, no están escritas por, como decía, Google. No están escritos por WordPress, estos complementos y temas y podría ser cualquier cosa, desde un solo desarrollador hasta un equipo. La huella de esos complementos o temas puede ser muy pequeña o muy grande. Pueden tener un buen historial de parchear las cosas rápidamente o no.

Y así depende. Entonces, a medida que WordPress crece en popularidad y el ecosistema crece en popularidad, puede asumir que los atacantes continuarán incrementando sus esfuerzos porque los atacantes van donde está el dinero, similar a por qué Windows tiene más malware que Mac en general. Eso es porque ahí es donde está la huella, y ahí es donde está el dinero.

Así que WordPress no es diferente y, a medida que aumenta su popularidad, puede esperar que los atacantes sigan haciendo lo que están haciendo. La buena noticia es que, en comparación con cuando inicié WP Engine hace cuatro años, el ecosistema es mucho más saludable.

Los desarrolladores de complementos, los desarrolladores de temas son más conscientes de que van a recibir aportes de los investigadores de seguridad u otras personas que noten las vulnerabilidades. Y la mayoría de ellos están desarrollando ese músculo de manera responsable para que puedan cambiar los parches muy, muy rápidamente.

Así que las cosas están mucho mejor de lo que solían ser. Hace cuatro años, muchos desarrolladores se sorprendieron cuando ocurrieron vulnerabilidades y no fueron realmente tan rápidos ni capaces de satisfacer las necesidades de sus clientes en términos de parches regulares.

Todos nosotros, como consumidores de tecnología, estamos acostumbrados, entre comillas, al "martes de parches" o nuestras actualizaciones periódicas de Apple, etcétera. Así que no nos sorprenden las vulnerabilidades. Sin embargo, nos sorprendería mucho si ese proveedor no parcheara algo de manera responsable y rápida.

Entonces, el ecosistema de WordPress es, en general, más saludable de lo que era, creo, hace cuatro años. Una vez más, WordPress Core es excelente, pero creo que los complementos y los temas generalmente se mantienen al día. Así que eso es bastante positivo.

ERIC JONES: Solo para hacer doble clic en algo que dijiste sobre WordPress Core, ¿qué tiene la naturaleza misma del software de código abierto que tal vez ayude con ese problema de seguridad? Porque creo que ese es uno de esos conceptos erróneos y mitos que existen de que, de alguna manera, el software de código abierto no es fundamentalmente seguro.

BRENT STACKHOUSE: Bueno, esa es una gran pregunta. Y estaría interesado en los pensamientos de Joe sobre esto. Y no es por molestarte, Eric, pero soy lo suficientemente mayor. He visto que lo que entendemos por código abierto cambia bastante con el tiempo.

El código abierto en el pasado solía ser proyectos muy conocidos como Apache, o, digamos, OpenSSH, o, digamos, Linux, y cosas así, y cuando decimos código abierto en ese entonces, eso es lo que normalmente éramos. refiriéndose a.

Y, sí, había muchos proyectos secundarios, terciarios, cualquier cosa más pequeña que no estaban tan bien mantenidos, etc. Ahora, lo que creo que queremos decir con código abierto es prácticamente cualquier cosa que esté en GitHub, cualquiera que más puede agarrar.

Estás hablando de bibliotecas, un código muy pequeño que cualquiera podría decir, oh, se ve muy bien en función de sus características, que vamos a incorporar eso. Y hablaré un poco más tarde, ya que Joe aludió a los problemas de la cadena de suministro. Hablaré un poco más adelante sobre los desafíos específicos del desarrollador en términos de mitigación de riesgos de la cadena de suministro.

Porque es de código abierto. Vuelvo a pensar en tu pregunta, Eric, sobre WordPress. Es genial que la fuente esté ahí fuera. Mucha gente lo está mirando. Creo que eso también es cierto en el pasado con Apache y cosas así. Cualquier cosa que se use de forma generalizada va a recibir un gran escrutinio tanto de los buenos como de los malos, y creo que eso es algo bueno. La seguridad a través de la oscuridad nunca ha sido una buena práctica. Y tener el código disponible es genial.

Pero el código abierto equivale a una mejor seguridad que el cerrado o viceversa es una pregunta difícil de responder. Porque literalmente son manzanas y naranjas. Creo que WordPress como equipo ha hecho un gran trabajo utilizando otras entradas además de su propia inteligencia, como el uso de un programa de recompensas por errores. WordPress Core ha estado haciendo eso durante años. Creo que eso es inteligente.

Indudablemente, tienen investigadores no afiliados que los envían regularmente con sus hallazgos. Y los equipos inteligentes toman esas entradas y hacen lo correcto. Estoy seguro de que ellos mismos se están sometiendo a pruebas de penetración, etc. Así que hacemos cosas similares en WP Engine, pero eso es normal para el curso.

Joe, ¿alguna idea sobre eso? Lamento tomar el control, Eric, pero...

ERIC JONES: No, eso es perfecto.

JOE SULLIVAN: Creo que aciertas mucho en los puntos altos. Cuando pienso en software de código abierto, cuando pienso en software de cualquier fuente, creo que tenemos que evaluarlo antes de ponerlo en nuestro entorno. Y, a veces, el software de código abierto será la mejor opción que algo propietario. Porque sabes que? La luz del sol mata la infección.

Y lo que tenemos con una gran cantidad de software de código abierto es que muchas otras personas también lo están mirando. Creo que eso es algo en el mundo de la seguridad en general que no hacemos lo suficientemente bien, todos nos sentamos en nuestros pequeños equipos y rincones, y tratamos de resolver todo nosotros mismos.

Involucrar a la comunidad es algo bueno. La transparencia y el diálogo sobre los riesgos en torno a determinadas piezas de software es algo bueno. Y estamos mejorando en eso. Su ejemplo de un programa de recompensas por errores es otra forma de brindar transparencia e invitar a terceros a hacer agujeros.

El software de código abierto tiene mucha gente que lo mira cuando hablamos de las piezas de software de código abierto más utilizadas e importantes. Pero de la misma manera, no solo tomaría un código de GitHub y lo colocaría en mi producto sin examinarlo realmente.

También diría que debe tener la misma precaución cuando compre una licencia de software propietario. Todavía necesita ver quién lo está haciendo, qué prácticas tienen y qué tan sólido es.

BRENT STACKHOUSE: Sí, mucho de esto se trata, y este es un término nerd de riesgo, pero de seguridad. ¿Qué garantía podemos obtener de todo lo que estamos haciendo en un sentido técnico de qué tan seguros son una vez que hacemos A, B, C? Y muchas garantías, dependiendo de la situación con código cerrado, es más difícil de obtener.

En código abierto, puede obtener una mejor idea más fácilmente de quién ha hecho qué para revisar el código. Es un poco más complicado con código cerrado. Tiene que usar entradas indirectas que muestren que esta empresa ha tenido buenas prácticas de seguridad a lo largo del tiempo, etc.

Pero, sí, obtener garantías es al final del día lo que está tratando de hacer cuando está implementando, utilizando cualquier tecnología en general. Gracias.

ERIC JONES: Entonces, para los desarrolladores que existen, ¿cuáles son esas garantías específicas que ambos buscan en las empresas? Si estos proyectos o piezas de software tienen estas cosas, entonces las considera buenas, un poco más seguras de lo que podrían ser de otra manera.

BRENT STACKHOUSE: ¿Quieres una respuesta de WordPress? Dejaré ir a Joe si quieres empezar en general.

ERIC JONES: Sí, Joe, si pudieras brindar una perspectiva amplia, y luego, Brent, puedes brindar la perspectiva más específica de WordPress.

JOE SULLIVAN: Sí, desde donde me siento, pienso en esa pregunta como comprador y como vendedor porque trabajo en Cloudflare, donde las personas implementan nuestros productos. Y la pregunta número uno que tiene cualquier cliente de Cloudflare antes de implementar Cloudflare es, ¿debo confiar en Cloudflare? Porque estamos sentados frente a todo su negocio. Y ese es un lugar realmente arriesgado para poner a alguien a menos que confíes en él.

Pero yo también, debido a que estamos creciendo y necesitamos construir nuestros productos, también dependemos de terceros. Así que estoy en el lado receptor de las preguntas difíciles y estoy en el lado que hace las preguntas difíciles.

Y, mira, ninguno de nosotros tiene el tiempo para ir o los recursos para entrar y auditar cada vez que vamos a trabajar con un tercero. No tenemos equipos lo suficientemente grandes. No tenemos la habilidad establecida para. Entonces comenzamos con las certificaciones de seguridad como un concepto que importa aquí.

Cuando digo certificaciones, me refiero a cosas como un SOC 2, un SOC 2 Tipo II como el que tiene WP Engine, o el ISO 27001, o PCI. Cuando escuche esas palabras y certificaciones, lo que debe pensar es que un tercero usó un conjunto reconocido de estándares para ingresar y auditar a esa empresa y evaluar si estaban cumpliendo con todos los controles para esa área.

Entonces, cada uno de nosotros: Cloudflare tiene un informe SOC 2 Tipo II que podemos compartir. WP Engine tiene un informe SOC 2 Tipo II que podemos compartir. Y lo bueno de cuando digo Tipo II, significa que no fue solo una auditoría de un punto en el tiempo. Fue un período prolongado de tiempo.

Entonces, por ejemplo, con nuestro SOC 2 Tipo II, significa que durante el último año, en cualquier momento durante el tiempo para el que existe esa certificación, cumplimos con esos controles mínimos de seguridad. Muy a menudo eso es suficiente para un cliente. Como, oh, esa empresa tiene un SOC 2 Tipo II. Está bien, confiaré en ellos.

Pero entonces es posible que desee profundizar un poco más en función de su implementación específica. Entonces, cuando pienso en comprar un producto, no solo pienso en la calidad del código, sino también en cómo se integra con mi entorno.

Entonces, algo que me importa mucho es la autenticación. ¿Puedo integrar eso con mi inicio de sesión único para poder administrar quién dentro y fuera de mi organización tiene acceso a él? Porque de ahí, como dije antes, proviene un gran porcentaje de los problemas de seguridad.

Entonces, desea elegir productos como WP Engine, donde puede integrarlo con su SSO y dejar que la seguridad se ejecute a través de las herramientas sin tener que hacer mucho trabajo práctico. Entonces, para mí, son certificaciones más la combinación de todo lo demás que desea para su entorno específico.

ERIC JONES: Y, Brent, devolviéndote la pregunta, ¿cómo piensas sobre eso en un contexto de WordPress?

BRENT STACKHOUSE: Sí, creo que eso es genial. Cuando las personas buscan extender el ecosistema de WordPress, por así decirlo, mediante el uso de complementos y temas, un par de cosas que deben buscar incluso desde un contexto comercial o una capa comercial son, qué tan popular es este fragmento de código, complemento o ¿tema? ¿Y puedo ver en su registro de cambios que se actualizan regularmente, incluso para actualizaciones de seguridad?

Esas son medidas o insumos muy cualitativos, pero siguen siendo relevantes. Por lo general, los desarrolladores de complementos o los desarrolladores de temas que tienen una gran presencia (tienen muchos clientes) tienen algo que perder y ganar, por así decirlo, al mantener bien o mal su código, dependiendo de la forma en que lo haga. quiero darle la vuelta a eso. Y simplemente elegir los más comunes para lo que necesite es generalmente una buena práctica.

A nivel de desarrollador, puede aplicar más control, por así decirlo. Puede usar herramientas de seguridad de aplicaciones estáticas para un complemento determinado. ¿Es probable que encuentre algo que otro investigador de seguridad no haya encontrado? Tal vez no, pero sigue siendo una buena idea ejecutar esas cosas a través de cualquiera que sea su herramienta. Y existen muchas herramientas gratuitas de código abierto o incluso herramientas comerciales con licencias gratuitas o de muy bajo costo que pueden permitirle obtener una mayor seguridad sobre cualquier código que esté utilizando en su entorno.

Una cosa que Joe mencionó y de la que también hablaré un poco con usted es que WP Engine también es tanto un consumidor de código como un productor, por lo que también somos un proveedor de servicios y estamos muy preocupados por la integridad de nuestro esfuerzos de desarrollo de extremo a extremo. Y es un desafío continuo.

Entonces, una de las cosas para nuestros desarrolladores que ejecutan sitios de WordPress es que deben ser conscientes, con suerte, del contexto de riesgo de su organización. ¿En qué vertical están, por ejemplo? ¿Cuánta tolerancia tiene la organización para que sucedan cosas malas? Ciertos sectores u organizaciones son mucho más susceptibles a cosas como ataques DDoS, etc.

Entonces, pensando en eso y potencialmente codificando esas cosas, no puede codificar DDoS, pero ciertamente puede ser consciente de ello y sacarlo a la luz. Creo que es muy importante que los desarrolladores hagan lo correcto.

ERIC JONES: Cambiando un poco de tema, y ​​con el objetivo de tratar de proporcionar algunas recomendaciones muy específicas, Joe, desde una perspectiva de seguridad de alto nivel, ¿qué recomendaría que hicieran los propietarios de sitios web para ayudar a reforzar su seguridad?

JOE SULLIVAN: Sí, tal como lo veo, una onza de prevención vale una libra de cura. Y, en el contexto de la seguridad, eso significa elegir las herramientas y plataformas adecuadas que va a usar antes de comenzar en lugar de intentar construir algo, y ahora veamos cómo arrancamos la seguridad por encima de eso.

Entonces, cuando selecciona plataformas, cuando selecciona herramientas, cuando selecciona código, debe pensar en ello teniendo en cuenta la seguridad desde el principio. Entonces, como dije, si puede lograr que la seguridad ocurra automáticamente a través de las herramientas que elija, estará en un lugar mucho mejor que si tiene que contratar personas para que entren al lado y hagan una un montón de auditorías, y luego tratar de arreglar todo mientras el barco navega por el océano.

No puedes parchearlo de esa manera. Entonces, para mí, siempre estoy buscando, ¿qué obtengo de la caja desde el punto de vista de la seguridad? ¿Cuáles son los ajustes que hay para mí? Y si tomo los conceptos básicos de seguridad, creo que en realidad solo hay algunas áreas.

El número uno, para mí, es siempre la gestión de acceso e identidad. Por eso hablé sobre la capacidad de integrar el inicio de sesión único desde el principio. Si estuviera iniciando una empresa, lo haría, una de las primeras cosas que elegiría sería la configuración correcta de inicio de sesión único que escalará con mi organización. Y siempre trataría de elegir productos que se integren con él.

Lo segundo en lo que pensaría es, OK, voy a tener un montón de código frente a Internet. ¿Cómo resisto los ataques de Internet? Voy a tener que ir por mi… Brent mencionó los ataques de denegación de servicio.

¿Tengo que descubrir personalmente cómo tener balanceadores de carga y administrar todo eso y comprar productos como Cloudflare? ¿O viene integrado con una plataforma que estoy comprando para no tener que pensar en la seguridad? Sé que ya está integrado, y así sucesivamente. Así que revisaría metódicamente a mis empleados y la administración de identidad y acceso, el código de acceso a Internet.

Y luego, como el tercer pilar es probablemente, del que realmente no estamos hablando aquí, ¿cómo configuro las computadoras portátiles y cosas así?

ERIC JONES: Y, Brent, tal vez hablando contigo, ¿cuáles son algunas cosas específicas en las que los desarrolladores de WordPress deberían pensar para crear los sitios más seguros que puedan?

BRENT STACKHOUSE: Sí, mi respuesta inicial es que es interesante. Mucho de lo que estamos hablando es una decisión sobre cuándo construir versus comprar. ¿Vas a crear tus propios complementos y todo lo que quieras hacer para ampliar tu ecosistema de WordPress? ¿O vas a comprar por así decirlo aunque sea gratis?

Pero esto se aplica, creo, a Joe y a mí también, en el sentido de que consumimos el código de otras personas a través de GitHub o cualquier mecanismo y posiblemente podríamos contratar desarrolladores y hacer todo eso desde cero. O podemos usar algo que alguien más ya haya hecho.

¿Y por qué recrear la rueda cuando no es necesario? Pero entonces, ¿cómo se asegura de que el código que está utilizando está en buen estado? Volviendo específicamente a WordPress, creo que hay un par de cosas: esto probablemente sea de sentido común para una audiencia de desarrolladores, pero lo diremos de todos modos. Cuando esté codificando, codifique de forma segura, lo que significa saber lo que está tratando de hacer. Trate de limitar lo que está tratando de hacer en términos de sus funciones, todo ese tipo de cosas.

Pero tenga en cuenta el OWASP Top 10. OWASP Top 10 probablemente sea bien conocido por nuestra audiencia. Pero, de nuevo, los conceptos básicos son importantes, como Joe aludió anteriormente, por lo que los conceptos básicos para desarrolladores ciertamente incluyen OWASP Top 10.

Y luego use una de esas herramientas de seguridad de aplicaciones estáticas que mencioné que son muy buenas implementadas previamente o durante la implementación. Puedes hacerlo automágicamente, por así decirlo. Y asegúrese de que el código que está enviando esté realmente en buen estado y que no haya vulnerabilidades obvias conocidas con su propio código si está desarrollando un código personalizado.

La tercera cosa se relaciona con el tema de la cadena de suministro del que hablamos. Y GitHub tiene algunas funciones gratuitas que realmente pueden indicarle cuándo sus dependencias ascendentes tienen vulnerabilidades conocidas. Así que Dependabot, un bot de dependencia, es una gran cosa que proporciona GitHub, y absolutamente deberías tenerlo habilitado en tus repositorios. Y en realidad puede crear relaciones públicas automáticamente. Y luego tendrá la opción de combinar eso si cree que lo necesita para que sus dependencias ascendentes al menos no tengan vulnerabilidades conocidas.

Presumiblemente, todo el código tiene errores incluso cuando lo envía y tiene un subconjunto de errores de seguridad, pero al menos debemos evitar los desafíos obvios a los que Joe aludió anteriormente. No queremos salir en los periódicos porque nos perdemos lo obvio. Oye, deberías arreglar las cosas. Entonces, sí, esas son tres cosas que creo que los desarrolladores podrían tener en cuenta para mantenerse fuera del fuego, por así decirlo.

ERIC JONES: Supongo que la pregunta para ambos es, ¿cuáles son las cosas que ven venir que no están del todo en el radar en este momento? ¿Y cuáles son las cosas en las que la gente, los desarrolladores y los propietarios de sitios web deberían estar pensando que no están pensando en este momento? Y esa es una pregunta abierta para cualquiera de ustedes.

BRENT STACKHOUSE: Bueno, sí, quiero participar porque Joe respondió a lo de Okta antes. Así que ese grupo en particular, esto es interesante. Así que ya lo hemos visto. Así que ni siquiera puedo decir que esto casi se está desmoronando.

Pero el grupo que explotó a Okta y también otros grandes nombres que no necesitamos mencionar necesariamente en este podcast o esta entrevista, usan técnicas de ingeniería social muy, muy interesantes principalmente, ataques no muy técnicos en absoluto.

Entonces, tal vez los desarrolladores no sean susceptibles a este tipo de ataque. Depende de la organización y de dónde encaja el desarrollador. Sin embargo, cualquiera que actúe como personal de TI o persona con acceso a los activos, por así decirlo, para una organización determinada podría muy bien ser objeto de ataques de ingeniería social.

Eso es algo de lo que no nos gusta hablar porque no podemos arreglarlo técnicamente. Pero los humanos honestamente continúan siendo el punto débil. Pasar por la puerta principal, como lo llamamos, lo que significa un ataque externo, a menudo es técnicamente más difícil y requiere más trabajo para los atacantes. Y a veces, o con frecuencia, sufrirán ataques de ingeniería social. El phishing sigue siendo muy, muy eficaz a través de cualquier medio.

Así que creo que eso es algo que sigue siendo un desafío. Y las organizaciones probablemente no enfocan su tiempo en eso tanto como deberían.

JOE SULLIVAN: Sí, creo que otra forma de decir lo que dijo Brent con una voz ligeramente diferente es que en realidad no quiero que los desarrolladores pasen mucho tiempo con una bola de cristal, tratando de anticipar el próximo problema de seguridad. Es más importante hacer lo básico bien.

Y esos conceptos básicos se encargarán de la mayor parte de la próxima gran cosa, sea lo que sea. Y a modo de ejemplo, mencioné que ha habido un cambio fundamental en cuanto a la aparición del ransomware. Ha paralizado a las empresas como nunca antes lo había hecho el ciberdelito.

Pero no es como salir y comprar un producto para bloquear ransomware. Regresa y hace exactamente las mismas cosas que debería haber estado haciendo para lidiar con las amenazas anteriores. ¿Qué es el ransomware? Es software malicioso que se coloca en su entorno.

Bueno, cada vez que un intruso ingresa a su entorno, es malo. Así que tenemos el derecho, si seguimos enfocándonos en el perímetro y no permitimos que nuestros empleados se vean comprometidos o nuestro código se vea comprometido, entonces no tenemos que lidiar con ransomware.

Entonces, en lugar de sentarse y preocuparse por cuál es el próximo ransomware que aparecerá, siga concentrándose en lo básico. Y dejemos que el resto de nosotros en el mundo de la seguridad especulemos sobre el futuro.

ERIC JONES: Joe y Brent, muchas gracias por su perspectiva, su tiempo y sus consejos hoy. Mucho en lo que pensar a partir de los fundamentos correctos, la importancia de la transparencia, qué buscar desde la perspectiva de un seguro.

Y luego, quizás lo más importante de todo es que la seguridad nunca debería ser una idea de último momento. Tienes que tenerlo integrado desde el principio. Animo a todos, si están interesados ​​en obtener más información sobre las ofertas de seguridad de WP Engine o Cloudflare, consulten nuestros sitios web. Y, por supuesto, en WP Engine, tenemos una gran cantidad de información de seguridad disponible para todos en nuestro Centro de recursos si está interesado en una perspectiva específica de WordPress. Entonces, nuevamente, a todos los que sintonizaron hoy, gracias por dedicar su tiempo y acompañarnos hoy.