Transcripciones
1. INTRODUCCIÓN: Hola. Hola a todos.
Bienvenido a mi nuevo curso, que es la
seguridad de la cadena de suministro y Master Class. Mi nombre es Purg Law, y voy a
ser instructor durante la duración de este curso,
que es, por supuesto ,
sobre seguridad de la cadena de suministro de software Ahora bien, el propósito de este
curso es muy, muy sencillo. Quiero explicarte los fundamentos de
la seguridad de la cadena de
suministro de software, afirmar los fundamentos
al nivel avanzado, y vas a obtener una
comprensión muy completa de la cadena de suministro de software Cuáles son sus componentes, cuáles son los grupos de interés
y los diversos tipos de riesgos y
problemas de seguridad que pueden comprometer
la integridad y seguridad de su software. Entonces vas a entender todos los
riesgos que hay ahí, y te daré los
conocimientos que
requieres para implementar un programa adecuado de
seguridad de la cadena de suministro. Y muy, muy importante.
Dije un programa de seguridad. No quise decir que no
dijera un producto de seguridad porque desafortunadamente
es muchas veces donde la
gente se confunde. Piensan que la seguridad de la cadena de
suministro de software se trata de implementar un software
u obtener la certificación, y eso no puede estar
más lejos de la verdad. Una seguridad de la cadena de suministro de software es un completo como se puede decir, un nicho dentro de la ciberseguridad, que necesita para
comprender diferentes riesgos y
cómo mitigarlos. Vamos
a ver algunos estudios de caso también dentro de la industria,
cómo sucedieron y cómo puedes usar
entenderlos para protegerte aún más de
convertirte en presa los mismos problemas
que hay ahí. Ahora, ¿quién soy? Mi nombre es Kamchal y soy un líder
profesional de ciberseguridad
multipremiado , he escrito, Bien, me
llamaré líder He estado en una industria por alrededor de 21 años más
dentro de la ciberseguridad He sido conferencista, instructora. También soy coach de carrera. Ayudo a la gente a entrar en la ciberseguridad Tengo un canal de YouTube llamado el chico de Seguridad en la Nube en el que hablo de
seguridad en la nube e IA. También soy
autor de bestsellers y creador
de cursos,
como he mencionado Entonces solo para darte esa
seguridad de que sí
sé un poco de
lo que estoy hablando, estos son algunos de
mis libros que están escritos sobre gobernanza de IA
y ciberseguridad Tengo muchos cursos
en esta plataforma. Sobre ese tema. También
he escrito libros sobre Zero Trust y Comtea, certificaciones de
ciberseguridad, muchos otros temas, Estoy ahí en Substack. un boletín gratuito ahí.
También estoy ahí en LinkedIn. Cloud como mi canal de YouTube se llama el tipo de Cloud
Security, y estoy ahí en Twitter, así que siéntete libre de
contactarme ahí. Siempre feliz de saber de
las personas que han tomado mis cursos. Ahora, demos un paso
adelante, atrás, perdón. Hablemos de
la cadena de suministro cuando hablamos de
la cadena de suministro. Ahora puede que no esté consciente, pero la cadena de suministro
es fundamental para nuestras vidas. ¿Y qué es una cadena de suministro? Es una red de
individuos y empresas que están involucrados en la creación un producto y
entregarlo al cliente, ¿verdad? Y cuando compras
algo, ya sabes, como de Internet
o de un producto, y la mayoría de la gente no está al tanto. Por lo general, es un viaje
muy largo desde la idea original hasta
el momento de la entrega. Y hay mucha, como, gente involucrada desde el
almacén hasta la empresa, el transporte hasta que lo
consigues, ¿verdad? Y hay muchos muchos que ustedes llaman
actores involucrados ahí. Y de lo que no te das cuenta es que hay muchas,
muchas oportunidades, también para que algo
suceda a medida que el producto
se mueve por este camino, las mercancías que van
avanzando, ¿verdad? Todos estos son
temas. Los problemas de seguridad están presentes en cualquier punto
de la cadena de suministro. Y la mayoría de la gente no está al tanto, pero la seguridad de la cadena de suministro ha
sido parte de nuestra existencia. Durante miles y
miles de años, como cuando las especias se
transportaban de este a oeste o cuando los barcos transportaban mercancías
entre continentes, ¿verdad? O cuando las tropas militares
transportan alimentos y
armas durante las guerras, todas las situaciones, las
personas están preparadas para los ataques y
defienden sus suministros. Por lo que el artículo podría llegar
al destino previsto. Y lo mismo es lo mismo
se aplica también para el software. Así que imagina construir
un auto. ¿Correcto? No fabricarías las
piezas desde cero, ¿verdad? En cambio, obtendrías los
diversos componentes, las llantas, el motor, la electrónica de
varios proveedores diferentes en una fábrica, y
luego lo montarías. Y así es de la misma manera. El mismo principio
se aplica también al software. Y aquí es donde entra en juego la cadena de
suministro de software. Se refiere a la secuencia
de procesos involucrados en el desarrollo despliegue y mantenimiento de aplicaciones de
software, básicamente todo lo
que se necesita para crear un software desde despliegue del código
fuente
hasta la producción, ¿verdad? En los entornos actuales,
es muy, muy raro que las empresas creen software
completamente desde cero. En cambio, lo que hacen es confiar en la gama
de bloques de construcción, como bibliotecas de código abierto, herramientas
para desarrolladores,
implementaciones basadas en la nube, ya sabes Y cada uno de estos
componentes forma parte de una larga cadena de suministro desde la infraestructura de TI, el código
fuente, ¿verdad? Y la cadena de suministro de software, se refiere a la secuencia de procesos que están involucrados
en conseguir este software. Entonces esto puede ser el código fuente, las bibliotecas de terceros
que están involucradas, los sistemas de construcción y empaque, los canales de distribución, las infraestructuras de despliegue ,
todas ellas,
vienen aquí. Y así es
como se ve desde los distintos
niveles, ¿verdad? Al igual que, los desarrolladores
confiarán cuando escriban el confiarán en numerosos
componentes externos al
desarrollar software. Esto puede ser una biblioteca de
código abierto, un tercero, API
o un servicio en la nube. Lo usan dentro de
su entorno, y luego lo envían
a un sistema de bits, que crea como un artefacto de
software y va a un repositorio, y
luego se implementa No te preocupes si no estás
familiarizado con estos términos. Vamos a
profundizar en cada uno de estos, software, solo
estoy tratando de
hacerte entender que el software generalmente
es desarrollado por múltiples individuos que podrían ser parte de múltiples organizaciones
diferentes. Y con el tiempo, miles de personas pueden haber contribuido
a un software en particular. Entonces hay que asegurarse de
que entiende. Donde
podrían entrar los temas de seguridad, ¿verdad? Y aquí es donde entra en juego la seguridad
de la cadena de suministro de software . Esto asegura la
integridad, seguridad y confiabilidad de
los componentes y procesos
involucrados en el desarrollo, distribución y
mantenimiento del software. Desea asegurarse de que su software
no esté siendo manipulado con compromiso en ningún
momento del ciclo de vida Y la
cadena de suministro, no
solo no estamos
hablando solo del código, sino también de las
bibliotecas, herramientas y servicios de terceros. Depende de la
infraestructura. Así que la
seguridad de la cadena de suministro de software lo abarca todo. seguridad de la cadena de suministro de software no
es una certificación que obtenga. No es un producto que compres. Abarca todos
estos procesos. ¿Bien? ¿Y por qué es tan importante? Bueno, en pocas palabras, esto puede
ser un punto ciego masivo. ¿Correcto? La mayoría de las empresas,
lo que hacen
es enfocarse en asegurar
sus propios entornos, su propio código,
hacen capacitaciones y se aseguran de que
todo sea seguro Y se
olvidaron por completo de las bibliotecas de terceros, los componentes de terceros
que están ahí. Y los atacantes no son estúpidos. También son conscientes de ello. ¿Por qué querrían
atacar de frente cuando saben que la
compañía se está asegurando a sí misma, cuando solo pueden colarse a través de un componente de terceros, a través de una biblioteca de terceros, a través de algún otro
tipo de puerta trasera que la
compañía no conoce Y desafortunadamente,
como yo hay una falta de conciencia y
controles en torno a esto. La mayoría de las empresas piensan que comprarán un producto y su cadena de
suministro es segura, o harán una lista de
verificación, verificarán a su proveedor y ahora
estamos seguros o
facturarán a MFA Todas estas cosas
son importantes. Por cierto, no estoy diciendo que
esas cosas no sean importantes, pero la seguridad de la
cadena de suministro de software es mucho, mucho más que eso. Y hay una
falta general de conciencia, razón por la
cual hice
este curso aquí. ¿Y por qué debería importarle? Quiero decir, no puedo enfatizar esto lo suficiente cuando como hace
unos años, victorias
solares se
vieron comprometidas, ¿verdad? Creó conciencia sobre la seguridad de la cadena de suministro de
software. Y voy a hablar a detalle sobre las victorias solares pero en resumen,
comenzó en octubre de 2019 y permanecen desapercibidas
hasta diciembre de 2020 Y para entonces, 18,000 clientes habían sido
puestos en riesgo, ¿de acuerdo? Microsoft confirmando que se habían librado tantas
empresas, incluyendo incluso
gobiernos de Estados Unidos, ¿verdad? Y el solar gana, tuvieron que
conformarse con, creo, una demanda de 26 mil millones de dólares con sus inversionistas debido a todas las
pérdidas financieras que se produjeron Y esto no incluyó
los millones gastados
por los vientos solares y sus
clientes o la respuesta a incidentes, las investigaciones de
amenazas, las investigaciones de
amenazas, inactividad, las remediaciones,
la pérdida de ingresos. que puedas entender cuán poderoso
fue este ataque y de manera similar, Log for J, si estás familiarizado, si estuviste en algún lugar en
diciembre de 2021 en ciberseguridad, estoy seguro de que sabes cuántas vacaciones de
personas se
vieron comprometidas debido a
este labrario popular, se comprometió, y estuvo presente en millones y
millones de entornos, y todos ellos tuvieron que hacer
un riesgo para asegurarse de que no
fueran vulnerables. Entonces la seguridad de la
cadena de suministro de software no es una broma. Puede llevar a ataques cibernéticos
devastadores si no lo está
asegurando adecuadamente. Entonces, ¿para quién es este curso? Esto es para, por supuesto, las profesiones de
ciberseguridad que quieren obtener una comprensión adecuada He utilizado todos mis
conocimientos que tengo sobre seguridad de la cadena de suministro de
software
y lo puse en este curso También es para desarrolladores
que quieran entender el contexto más amplio del
código, la seguridad del mismo. Este profesionistas,
si quieres
refinar tus conocimientos sobre riesgos e incluir también los riesgos de la
cadena de suministro de Suffa Y por supuesto,
líderes de seguridad como CIOs,
CTO, directores de
seguridad de la información, cualquiera que esté interesado en entender sobre la seguridad de la cadena de
suministro de software, felices de tenerte
en este curso Y como usar este
curso, por favor, hay
que entender e implementar las estrategias
que voy a estar delineando y distanciar
su cadena de suministro de software con
estas prácticas No solo tomes este curso
y luego olvídate de ello. Por favor aplique los conocimientos de los
que estoy hablando. Conociendo que no
estás aplicado, vas a olvidarlo, y luego crear un programa de
seguridad de cadena de suministro de
software adecuado . Ese va a ser tu
proyecto para este curso. Quiero que lideres, uses
los conceptos que
te enseño y los apliques dentro de
tu empresa y hagas un hueco. Eso es de lo que estamos
cubriendo. Ahora, software, ya estamos a
punto de comenzar. Recuerda, el software
está en todas partes. Trillones de líneas de
código fuente están presentes en todas partes, y una sola
vulnerabilidad de software puede impedir empresas
enteras
hagan negocios y causar miles de millones de
dólares en daños No más que nunca, necesita
comprender la cadena de
suministro de software, la seguridad. Entonces espero que esto te dé
una buena comprensión y te
motivó a
aprender realmente sobre este tema. Empecemos. Espero que
estés tan emocionada como yo, y te veré en la siguiente
lección. Muchas gracias.
2. Comprender la cadena de suministro: Hola a todos.
Bienvenido a esta lección en la que
vamos a entender la cadena de suministro de software. Antes de comenzar a asegurarlo, debe
comprender cómo
funciona
la cadena de suministro de software en el mundo actual, y luego vamos a
saltar a la parte de riesgos. ¿Bien? Entonces de esto es de lo que estás hablando en esta lección, que es la cadena de
suministro de software, los conceptos clave que
debes tener en cuenta y los diferentes tipos de
entornos que hay ahí. Y esto es como un curso
fundacional que va a establecer la
línea de base para todo el curso Entonces, si no estás al tanto de lo que es la cadena de
suministro de software, por favor asegúrate de
tomar esta lección,
y no vas a creer
la cantidad de profesionales de seguridad que he
visto que cometen este error. Lo que hacen es saltar
inmediatamente al riesgo
sin antes obtener una comprensión
o una apreciación lo que es la cadena de
suministro de software, cuáles son los diferentes
entornos y cómo funcionan. Entonces ya hemos hablado de esta definición antes, revisión
muy rápida. Cadena de suministro de software,
como hablamos, la secuencia de procesos
involucrados en el despliegue, desarrollo, mantenimiento
de aplicaciones de software. Básicamente, todo lo
que necesita para construir un artefacto de software desde desarrollo del código
fuente
hasta la implementación de producción, que viene dentro de la cadena de suministro de
software Hablamos antes
de cómo las empresas, es muy raro que
creen ein desde cero de ancho. Dependen de bloques de construcción como bibliotecas de código abierto, herramientas
para desarrolladores, servicios SAS. Todos ellos se unen para hacer este
paquete de software, ¿verdad? Y en todos ellos,
hay un potencial de que ocurran riesgos
de seguridad. Entonces, ¿cómo se ve un entorno
típico de
desarrollo de software hoy en día? Un entorno
de software, lo siento. Entonces así es como se
ve. Vamos a ir paso a paso como se necesita. Y antes de que saltes
sobre mí y empieces a gritar que no es así
como es mi entorno, sé que cada ambiente
es diferente, pero este es el
más común como, estos son los
atributos que
estarán presentes en prácticamente todos los
ambientes que hay ahí Entonces, antes que nada, comencemos con el
entorno de desarrollo. Aquí es donde ocurre la
magia, ¿verdad? Los desarrolladores utilizan este entorno
para escribir y probar código. Crean nuevas características
y experimentan con ideas. Es como su
espacio de trabajo, ¿verdad? Permitirles escribir código y dar vida a sus visiones. Y el entorno de desarrollo suele estar equipado con
diversas herramientas y marcos, que no están presentes en
otras máquinas de negocio. Entonces esto es como un ambiente
especial. Suelen tener más
privilegios. Entonces, ¿qué hacen? Utilizan su entorno de
desarrollo integrado, sus estaciones de trabajo, que
tiene su software de codificación Para escribir código, que se
empuja a un repositorio de código. Un repositorio de código puede ser como un servidor compartido que
contiene el código A partir de ahí, la plataforma de compilación, toma su código y se
convierte en un artefacto Ahora, los desarrolladores podrían estar usando dependencias
en su código, o cuando se está construyendo, podría extraer dependencias Las dependencias son, como dije, estos bloques de construcción, ¿verdad? No vas a escribir
todo desde cero, ¿verdad? Si estás escribiendo código Python, estarás usando
varias bibliotecas. Entonces, todas estas dependencias,
la plataforma de compilación
utilizará para construir su software, y así es como
funciona el entorno de
desarrollo . Entonces escribo código. Entra en un repositorio de código,
donde el entorno de compilación, genera
compila este Extrae todas las dependencias
que se requieran. Podría ser dentro
del entorno, podría ser un informe público, que se almacena en Internet. Pero así es como se
ve típicamente el entorno de desarrollo. Entonces después de eso, lo que viene, viene el
entorno de pruebas. Entonces, una vez que se escribe el código, hora de evaluar su robustez
y funcionalidad, El entorno de pruebas,
es como un lugar controlado donde realiza varios tipos de pruebas como pruebas unitarias, pruebas de
integración, pruebas de sistemas
, aseguramiento de calidad. Estás
evaluando meticulosamente este código, ¿verdad? Contra casos de prueba predefinidos para averiguar si hay algún
problema. Ahora, esto se puede
automatizar completamente con
muchos entornos. Tienen DevOps y DFSycoVs. Entonces podrías tener pruebas completamente
automatizadas. O podrías tener a una persona sentada ahí que esté
haciendo las pruebas, y no vas a creer que todavía
sucedemos. Tienes muchos equipos de control de calidad
y pruebas que están ejecutando, están
ejecutando esas pruebas automatizadas, pero hay una persona
mirándolo. Entonces hay varias
formas de hacerlo. Pero normalmente
tienes un entorno de pruebas y un entorno UAT donde se prueba
el código para
asegurarte de que está libre de bots ¿Bien? ¿Qué pasa después de esto? Entonces después de esto,
tienes algo llamado pre prod o ambiente de
puesta en escena. Entonces esto es como una brecha entre las fases
de prueba y producción. Esto suele ser una réplica
del entorno de producción. Permite a los equipos validar si el software
es comportamiento. Está funcionando correctamente en
condiciones del mundo real, ¿verdad? Como dije, está muy cerca del ambiente de producción. Por lo tanto,
les permite probarlo de estrés y les permite ver varios cómo funcionará
realmente el software, ¿sabes? Debido a que el entorno
de pruebas UAT, es como un entorno de prueba No representa
el mundo real. Entonces el preprod y el ambiente de puesta en
escena, esto es esto es muy, muy cerca de como
va a funcionar
el ambiente de producción como Y mucha gente usa preprod y puesta en escena
indistintamente Hay diferencias sutiles. Pero por lo general, en todos los ámbitos, usan bastante
indistintamente, honestamente hablando dentro de
lo que he visto ¿Y cuáles son los beneficios de
usar estos entornos? Como dije, pruebas de carga, pruebas de
rendimiento, pruebas esfuerzo, lo que
no se puede hacer en
entornos UAT, ¿verdad Y te dan varias
ventajas porque te
dirán cómo verá
el cliente
real el software,
y él errores errores
con el rendimiento, y tú disminuyes la velocidad antes el software llegue
al cliente final. Te permite afinar el rendimiento identificando cualquier cuellos de botella
que pueda estar ahí, y te da una buena manera de juzgar si
el rendimiento del usuario, la satisfacción del usuario, cómo va a estar ahí
porque ahora te estás dando una muy buena idea de cómo va a
ver el cliente este software, y ese es el
beneficio de agregar el pre prod y la puesta en escena. Y como dije, esto está muy,
muy cerca del entorno de
producción, por lo que podría tener datos
reales aquí, los datos producción
reales
que se almacenan aquí. Y por último, es el ambiente
de producción. Por lo que este es el
destino final para su software, es un entorno en vivo donde los usuarios
finales interactuarán con
su aplicación o sistema. El software se implementa aquí, y debe
probarse y refinarse meticulosamente en los entornos anteriores
para asegurarse de que los clientes tengan una experiencia
perfecta Ahora, nunca he oído hablar
de ningún software que no tenga errores en ese entorno de
producción sin importar la cantidad de
pruebas que hagas. Pero siguiendo los pasos, te
da una muy buena idea, y te da la
oportunidad de eliminar cualquier error que pueda haber ahí. Entonces así es como se
verá un entorno de
software típico . Como dije, antes de
que te vuelvas todo loco y me
acuses de
perderme áreas críticas Como dije, sé que cada
ambiente es diferente, pero este es el más cercano
que los entornos. Por lo general, estas son
las formas más comunes se estructuran
los entornos de desarrollo de
software. Entonces espero que tengas una buena idea. Ahora vamos a
ir lo que vamos hacer es echar un
vistazo
a algunos conceptos
que están ahí,
que son Dev SecOps, pipelines CICD, artefactos, repositorios de
artefactos, repositorios
de
paquetes e infraestructura a hacer es echar un
vistazo
a algunos conceptos
que están ahí,
que son Dev SecOps,
pipelines CICD, artefactos, repositorios de
artefactos, repositorios
de
paquetes e infraestructura como COD. Puede que estés familiarizado con esto, pero deliberadamente lo he puesto aquí solo para ponerlo como actualización, porque todas estas áreas
entrarán en
juego cuando
hablemos de entrarán en
juego cuando
hablemos los riesgos de seguridad de la
cadena de suministro de software que hay ahí Entonces lo he puesto esto
como una revisión quid. Si sientes que eres muy bueno en todos estos conceptos, no dudes en saltarte esta lección. Pero yo recomendaría
tomarlo como una revisión rápida, así que los veré en la
siguiente lección. Gracias.
3. Riesgos de la cadena de suministro - 1: Hola a todos. Bienvenida.
Bienvenidos a la siguiente lección. Y aquí es donde realmente
empezamos a entrar en la carne
del curso, que es ahora vamos a hablar del riesgo de
seguridad, ¿verdad? La
cadena de suministro de software, riesgo de seguridad. Entonces, en la
lección anterior, te hablo sobre cómo suelen
configurarse
los entornos de desarrollo de software , ¿verdad? A muy trato de cubrir el entorno de
desarrollo de software más común y cómo funciona, y cuáles son los
diferentes conceptos
y cómo el software
se mueve a través de ellos. Ahora bien, lo que vamos
a hacer en esta lección, vamos a hablar
de los riesgos de seguridad, que son los riesgos de seguridad
en la cadena de suministro de sofás, cómo ocurren,
y vamos a hacer un análisis de incidentes
reales. Algunos de los más populares como eventos solares, Cord Cov cuando
terminé este curso, probablemente algún otro
ataque a la cadena de suministro podría haber ocurrido. Pero voy a cubrir los que cubren diferentes escenarios. Y que puede mostrarte
el impacto real. Entonces no es solo
teórico donde solo te
estoy diciendo que
estas cosas pueden pasar. Te voy a mostrar
realmente cómo sucedió y cuál fue el impacto y qué puedes hacer para protegerte realmente,
bien, evitar
que estas cosas sucedan. Entonces, si recuerdas, este es el diagrama que vimos
antes, ¿verdad? Teníamos el
entorno de desarrollador con el ID, empujando código al repositorio, la plataforma
bull entrará en acción, extraerá cualquier
dependencia y blanco, y lo va a empujar al entorno de prueba, y luego la preparación
para la producción Esto puede ser completamente
manual o esto puede ser un pipeline CICD, blanco,
empujando tu código Desde los diferentes
ambientes hasta
que se empuja al ambiente de
producción, y de esto es de lo
que hablamos. Entonces pensemos ahora en
los riesgos a un alto nivel. Ahora, empecemos
por el desarrollador. Ahora, los desarrolladores en la
mayoría de los entornos y como se llama desarrolladores, suelen tener privilegios bastante
poderosos. Tienen la
capacidad de mantener sus propios
entornos de desarrolladores porque necesitan esa flexibilidad para crear
nuevas aplicaciones y productos desde mi experiencia, a veces
pueden poner en
marcha máquinas virtuales como, ya
sabes,
sistemas operativos de doble barco, Linux y Windows. Y estos entornos, a
menudo a veces invisibles
para las organizaciones de TI. Por eso
los llaman shadow IT, ¿verdad? Y los desarrolladores creen que requieren de esta flexibilidad, ¿verdad? Necesitan la capacidad de
poner en marcha una máquina virtual, instalar aplicaciones,
administrar sus entornos. No quieren que sus laptops o sus escritorios
estén bloqueados, y quieren acceso administrativo
o avanzado de usuarios a sus sistemas porque si
detienes esta capacidad, no
tendrán la capacidad de
solucionar problemas para crear entornos, o tendrán que
pasar por docenas de aprobaciones para Si alguna vez has trabajado
en ciberseguridad, seguro
que debes haber
visto esto, ¿verdad Entonces empezamos eso es lo primero que hay
que pensar los
privilegios muy poderosos que
tienen los desarrolladores y a qué nos
llevará eso ya veremos. Entonces claro, viene
en código seguro. Y vamos a ver ¿ si el código que están
escribiendo es inseguro Lo empujarán
a un repositorio de código y luego se va a propagar por todos
los entornos, y ese código tiene
graves fallas de seguridad Y si eres proveedor de
servicios, como los vientos solares,
ese código inseguro propagará
por todas partes, ¿ Miles y miles
de personas porque no
lo
revisaste tú mismo, ¿verdad? Y el código se empuja para que me guste, ¿cómo se llama
un repo de código, verdad Ahora, el repositorio de código, puedes tener múltiples
compromisos aquí también, El repositorio fuente,
el repositorio de código, tal vez la
interfaz de administración no sea segura. Y el atacante puede usar la interfaz de administración
o comprometer el servidor subyacente para atacar
directamente el
código fuente y obtener acceso a él, y empiezan a
modificar el código. O podrían poner
algo de malware ahí, que se propaga
por todas partes Entonces piensa en el
repo de código que está ahí. Por supuesto, tienes
la plataforma construida y están estrechamente
integradas con tus repositorios de artefactos y
tus repositorios de paquetes Y muchas veces lo que hacen es
que empiezan a construir cosas y propagarlas por todos
tus entornos, ¿verdad Así que el atacante puede atacar a esa plataforma de
compilación entradas, como qué versión
usar y pueden redirigirla a algún código
malicioso, que la plataforma de compilación
con la propaga Y veremos esto en
el ataque de los vientos solares. Entonces pueden atacar cualquier parte
de la plataforma construida, incluidos sus servicios o la infraestructura
subyacente, y pueden alterar la forma en que se
factura, ¿verdad Y esto puede conducir. comprometer el repositorio de
artefactos como el paquete del
que hablamos, y pueden subir o publicar artefactos
alterados porque no
protegiste la interfaz de
administración Y por último, las dependencias, si nos fijamos en la parte superior y esta es una de las cosas
más comunes Y desafortunadamente, la
gente piensa que esto es solo lo único de la cadena de suministro de
software,
pero sus dependencias, porque está
utilizando una variedad de bibliotecas comerciales y de código
abierto de terceros está ahí,
y así es como se
configuran la mayoría de los entornos, ¿verdad Y entonces lo que va a
pasar es que
tendrás múltiples ¿Qué pasa
si un atacante compromete esta biblioteca Intentan introducir comportamientos
maliciosos comprometiendo esta biblioteca, y esta dependencia se va a propagar a lo
largo de tu código Tu código, tenemos un componente
inseguro, como hablamos de
Log for J, ¿verdad? Se propagará a su
entorno, y más tarde, cuando
se descubra una vulnerabilidad, atacante puede usar esto para
incorporarlo a su entorno Entonces este es solo el
entorno del desarrollador, ¿verdad? Y luego pasar a los otros entornos
como
el entorno de pruebas UAT, cuando estás haciendo las pruebas, a veces las empresas ni siquiera se molestan en hacer pruebas de seguridad No tienen idea de si
el código es seguro. Ya sea que el COO esté introduciendo alguna vulnerabilidad o no,
algo independiente Simplemente confían en el desarrollador. No vas a creer lo común que sigue
siendo esto, desafortunadamente. Para que las
pruebas de seguridad no estén ahí. Muchas empresas que he visto, hacen pruebas de seguridad, pero después de eso
no pasa nada. Entonces hacen una prueba de seguridad, y están bien, acaban de
publicar un informe. Estas son las
vulnerabilidades de seguridad. Nadie está mirando esas
vulnerabilidades, ¿verdad? Entonces la prueba de seguridad no
haces pruebas de seguridad solo por el bien de las
pruebas de seguridad, ¿verdad? Haces pruebas de seguridad para que
se corrijan las vulnerabilidades. Entonces este es otro tema. Las pruebas de seguridad
no están ahí. Entonces, por supuesto,
pasas a los entornos
pre orgullosos y de
puesta en escena. Y hablamos de que esto es
una réplica de producción. Esto no es tan seguro como
la producción. Es una réplica. Entonces alguien podría
comprometerlo y obtener acceso a los datos porque
tienes datos de clientes. no lo has enmascarado ni
lo anonimizas, por lo que la gente
podrá acceder
a estos datos Y por último, por supuesto, el ambiente
de producción. El entorno de producción, lo he mantenido fuera del alcance de
este curso porque, claro, eso es la ciberseguridad
tradicional Tendrás parcheo y
todas esas otras cosas. Pero eso también puede quedar
comprometido, ¿verdad? Porque quiero que lo
pienses desde la
perspectiva del panorama general. Estos son todos los ataques
que pueden ocurrir, ¿verdad? Y por último, claro, si miras las flechas que están conectando
esos entornos,
éste, el
pipeline CICD si estás usando,
si estás usando un pipeline CSED, hablamos de cómo la integración
continua lo probará
rápidamente empujará el
código y hará las pruebas, y luego el despliegue
continuo o empujará el código través del otro
ambientes, ¿verdad? ¿Y si alguien es capaz de
comprometer el pipeline de la CICD? Este ducto tiene acceso a
todos los entornos, ¿verdad? Así que en realidad pueden controlar
qué código se está empujando, qué tipo de pruebas
están sucediendo Esto es otra cosa que
hay que tener en cuenta. Es otra
cosa muy, muy peligrosa que puede pasar. Entonces este es el panorama general. Este es el tipo de ataques que
quiero que
pienses cuando
piensas en la seguridad de la
cadena de suministro, ¿verdad? ¿Y esta es mi opinión? Entonces podrías estar pensando, y esta es solo tu opinión
subjetiva. Entonces no, lo he basado en
un referente de la industria. Entonces esto es Salsa. Se dice que la
pronuncian salsa, que me gusta, pero los niveles de la cadena de suministro
para artefactos de software. Este es un referente de la industria. Pondré el enlace
en este curso. Entonces es un marco de seguridad. Es como una lista
de verificación de las mejores prácticas para evitar que la seguridad de su cadena
de suministro de software se vea comprometida, ¿verdad? Y se suele utilizar
en toda la industria. Es un muy, muy
buen independiente, es agnóstico de tecnología,
es agnóstico de proveedores Y es como un
conjunto de lineamientos. Lentamente se pueden adoptar lentamente y se establecen
por consenso de la industria. Y están establecidos.
Entonces, cualquiera que esté construyendo software, los
usa, ¿verdad? Cualquiera que esté
produciendo, consumiendo o proporcionando software como plataformas de
construcción o cualquier cosa, esto puede usarse para, como, obtener más confianza dentro seguridad de
su
cadena de suministro de software. Es como la colaboración
cruzada de la industria. Vamos a hablar de
esto más adelante. Pero es como un
proveedor completamente neutral, ¿cómo llamas framework para asegurar tu
software un plan Te da un vocabulario común para hablar sobre la seguridad de la cadena
de suministro de software. Y entonces esto es sobre lo que
construí este diagrama. Entonces esto es lo que queremos mostrar. Y esto es un referente
de la industria. Entonces voy a poner el enlace ahí. Ya ves, así
que no soy solo yo, estás pensando que solo estoy
hablando por mi propia opinión. Esto se basa en un referente de
la industria del
que hablé, y definitivamente recomendaría
más adelante cuando construyamos un programa de seguridad de
cadena de suministro de software para echarle un vistazo, ¿de acuerdo? Entonces ahora vamos a
hablar del riesgo clave para la seguridad. No voy a
hablar de ello en esta lección, porque ya
te he dado algunas cosas de las que hablar. Continuaremos
en la siguiente lección. Pero vamos a
hablar del riesgo clave para la seguridad. Todo el riesgo del que
hablamos en el diagrama, realidad
vamos a
profundizar en cada uno de
ellos y pensar cómo funciona esto y cuáles son las implicaciones de que ocurran
estos ataques. Entender estos, es
bastante crítico porque lo contrario no puedes asegurar algo si no entiendes
cómo sucede, ¿verdad? Entonces ahora vamos a
profundizar en cada uno de estos riesgos, y voy a
mostrarles el impacto de estas cosas que suceden. Bien, muchas gracias. Te veré en la siguiente lección.
4. Riesgos de la cadena de suministro - 2: Hola a todos.
Bienvenidos a esta lección. Y ahora vamos a
hablar de los riesgos clave de seguridad de los que hablamos
en el diagrama. Y vamos a
caminar uno por uno, que te hagas una mejor idea
de estos riesgos de seguridad. Y más adelante, cuando
empecemos a asegurarlos, vas a tener
una idea mucho mejor. Y vamos a
ver algunos estudios de caso también sobre los vientos solares y Kokov cómo estos riesgos pueden suceder realmente
y realmente comprometerse Voy a ir paso a
paso para
darle una mejor apreciación
de estos ataques. Entonces comencemos con
el número uno que es código inseguro Ahora bien, el código inseguro no es
quiero decir, honestamente hablando, esto es algo
que ha estado en la industria desde hace décadas, y ahora hay mucha
buena conciencia Es decir, comparado con
los otros ataques, yo diría que el código inseguro no
es tan grave La mayoría de las empresas, sé que han empezado a poner
medidas, pero este es el punto de partida. De todos los riesgos de
seguridad de la cadena de suministro de software Honestamente, como dije, la
raíz de todo mal, ya sea de primera
parte o de terceros, hay
que asegurarse de que su código sea seguro. Y el error que veo que cometen
muchas empresas,
aseguran su código de primera parte, que es su propio código, pero no
miran a terceros, y hay que tratar a
todos los códigos por igual. Tienes que
asegurarte de tener
esa seguridad de que ese
código ha sido asegurado. Y podría preguntarse, ¿cómo puedo asegurar el código de terceros? ¿
No tengo acceso a ella? Bueno, hay formas
de hacerlo. Puedes
preguntar al vendedor. Se pueden evaluar los procesos de gestión de
riesgos del proveedor, ¿
verdad? Entonces hay formas
de verificarlo, y lo vamos
a ver con más detalle. Donde hablamos de crear el programa de gestión de
riesgos de seguridad de proveedores. Pero el código
inseguro es más o menos si
no estás asegurando tu código, todos los demás controles
no importarán porque aquí
es donde estarán la mayoría de tus riesgos de
seguridad. Entonces estos son solo ejemplos. Solía mirarlos, y si conoces un poco de codificación,
es algo así como
un ataque de inyección que no estás
desinfectando el código, solo
estás aceptando código en tu entorno, y casi cualquiera puede simplemente pasar por alto este código para acceder a
tus bases de datos subyacentes, tu sistema
operativo subyacente Se llama ataque de inyección. Y no vas a creer
ni en 2024, veo gente que sigue cometiendo este error. Entonces
es increíble. Estaba viendo la
programación en 2002. Entonces ya son casi 22 años, y aún así este tema
sigue ahí, lo cual me pareció muy gracioso que
todavía este error esté ahí a pesar de todos los
avances que hemos hecho. Esto es otra cosa. Esto es como un ataque con bomba ZIP en caso de que
no estés familiarizado con esto, esto es como un
archivo que
no estás validando un
archivo ZIP o un archivo de archivo, solo lo
estás extrayendo
sin hacer ninguna Por lo que en realidad puede causar una denegación de servicio
al atacante. Se puede agotar el
dispace o la memoria
del sistema objetivo cuando
intentas extraerlo, ¿verdad Y honestamente, el
formato ZIP es el
que más se usa, pero prácticamente
puedes usarlo. Es como comprimir
un archivo grande que consiste en un solo
carácter, ¿verdad? Y puedes crear un archivo de un MB que se
descomprimirá a un GV Y en realidad
va a estropear el sistema operativo
porque
no estás haciendo ninguna validación. Entonces estos son otro ataque, que es por
tu código inseguro Y esto es, quiero decir,
cualquiera lo sabe. Esto es lo más antiguo y
lo más común, que son los secretos codificados duro. Como la gente es perezosa.
No quieren hacer validación segura y
nadie está mirando el código. Así que en realidad ponen en
los secretos codificados duro, y esto se empuja a un repositorio de código
público. Como asumiendo que estás usando
un segador de código público, alguien accede a
él y boom, tiene acceso a tu
entorno porque pones ID de usuario y
la contraseña
dentro de un segador de código Tantas empresas que conozco, son que tienen políticas de
contraseña muy estrictas, pero no
miran el código. Que está ahí, y así ni siquiera
están escaneando su código. Por lo tanto, esto puede llevar a los ID de usuario codificados, las contraseñas, las claves de acceso codificadas con
disco duro se pongan en un código y
se envíen al informe de código. Cualquiera que tenga acceso a
ese código
ahora puede pasar por alto y comprometer
su entorno. Entonces esto es solo para
mostrarte lo peligrosos que son estos ataques. Entonces esto era como un código inseguro. Pasemos al siguiente,
que es componentes inseguros de
terceros Y aquí es donde más se
enfoca cuando
la gente habla de seguridad de la cadena de
suministro, básicamente dependencias de
terceros vulnerables
o maliciosas dependencias de
terceros Ya sabes, hablamos de
esto antes que el
software moderno se basan en bibliotecas de
terceros o adios. Y si estas dependencias
están conteniendo vulnerabilidades o
tal vez código malicioso, pueden introducir riesgos en todo
tu entorno, ¿verdad? Y el software de terceros, piense en software de terceros es solo software de primera parte que está escrito
por otra persona. Así que al igual que la Nube es solo servidor que está
dirigido por alguien más. Dependencias de software de terceros,
puedes pensarlo. Estas son tus dependencias, pero escritas por alguien más. Todos los riesgos de los que
hablamos de codificación, se
llevan aquí también. Y estas vulnerabilidades pueden
entrar en tu entorno. Si el atacante es
capaz de comprometerlo. Esa dependencia, esta
dependencia ahora se utilizará para comprometer
tu entorno, ¿verdad? Y estas pueden ser
vulnerabilidades conocidas. Entonces no es como si estuviera oculto porque esta vulnerabilidad
se conoce desde hace
bastante tiempo, pero no puedes
arreglarla porque romperá tu aplicación o porque el proveedor no ha
lanzado una solución. Entonces hay que
pensarlo. Bien, ¿qué hago ahora? O, esto puede ser cero días, como el Lock inicial para J. ¿Recuerdas Log for J, verdad? Esto puede ser cero días.
Nadie lo sabía. De pronto, entra, y no
hay solución para ello. Y rápidamente, los atacantes pueden
empezar a manipularlo, empezar a tratar de comprometer
los entornos con él. Y esto es como las vulnerabilidades
inmediatas
pueden estar ahí que permanecen inactivas en una base de código durante
meses, años, incluso décadas Y cuando
finalmente se descubren
y anuncian a la gente de todo el mundo, están peleando. Me gusta saber si están usando este
software o no, bien, para averiguar si usan esta dependencia y
cómo protegerse de ser explotados. Los atacantes también están peleando. Por cierto, están
tratando de determinar quién está usando este software
vulnerable, y están tratando de crear hazañas para aprovechar
y comprometer el entorno Entonces es como que es como una carrera loca para que la gente
se entere, ¿verdad? Y así es como
suele verse. Entonces tienes un atacante, comprometen
este entorno. Comprometen un labrario de
terceros y este tercero labrarys
consiguiendo Se está propagando a miles y miles
de empresas,
cierto, como Lock for y tomemos
el ejemplo de las victorias solares Alguien comprometió el ambiente de los vientos
solares, y ese código que luego usamos para
empujar a través del medio ambiente. Entonces este es otro ejemplo
de cómo sucedió eso. Y así suele ser como
funcionan los componentes de
terceros inseguros , ¿verdad Hay que
pensarlo desde esta perspectiva. Entonces estas fueron la codificación de
primer nivel y las
dependencias de terceros Voy a desglosar esta lección en múltiples
partes porque
quiero que absorbas lo que
hemos hablado antes
de saltar a la siguiente. En la siguiente,
voy a hablar comprometer el reposo del código donde estás almacenando el código Recuerda cuando el desarrollador
solía empujar código, iría a un repositorio de código Entonces hablemos del
repositorio de código y lo que puede pasar. Gracias, y nos
vemos en la siguiente lección.
5. Riesgos de la cadena de suministro - 3: Hola a todos. Bienvenida.
Bienvenidos a esta lección. Y ahora vamos a
hablar del compromiso del repositorio de código Entonces, como puede ver, si
recuerda el diagrama, nos estamos moviendo lentamente a través de la cadena de
suministro del software. Y ya hemos hablado de repos de
código antes. Básico, piénsalo como una biblioteca
centralizada o un repositorio centralizado donde tus desarrolladores puedan
colaborar en el código, ¿verdad? Entonces escribo algún código y lo
empujo a un reporte de código. Otro desarrollador
también está escribiendo código. Están empujando
al mismo informe. Y el código, has
oído hablar de Github ampliamente. Por lo que se asegura de que todo
el código esté sincronizado. Y qué puede pasar, los atacantes pueden acceder a
este repositorio, ¿verdad mejor el software no
está asegurado, o tal vez comprometen al usuario
le enviaron un enlace malicioso, al usuario
le enviaron un enlace malicioso,
y él era como si pusiera su ID de usuario y contraseña, y
pudieron obtenerla. Ahora pueden manipular el código
fuente en la fundación. O incluso mucha
gente no está al tanto. El repositorio en sí se
puede utilizar para servir
ataques a los clientes Y a veces la
gente no es consciente de ello. Entonces está la seguridad
del repositorio en sí, asegurándose de que el
repositorio no se vea comprometido, y el repositorio en sí pueda
usarse como vector de ataque Y tomemos un ejemplo. Entonces por si acaso
no eres consciente de esto, creo que esto
sucedió en 2020, el malware del escáner pulpo Así que en realidad atacan. Lo que hicieron fue que tenían como un conjunto de repositorios
alojados en Github, y fueron involuntariamente,
la palabra clave aquí Sin querer, estaban
siendo utilizados para servir malware. Y en realidad, el
equipo de seguridad de
Github , lo investigaron, y se enteraron de
que lo que había pasado era que estos repositorios no habían sido asegurados y
estaban siendo utilizados para servir malware en todos
los ámbitos, Y los dueños de
los repositores, desconocían
completamente Estaban cometiendo como código
malicioso en
los repositorios Cuando están haciendo
eso tirando del código, en realidad
estaban
tirando malware, y proporcionan un alto
nivel, ¿cómo se llama? Lo que hace bien, básicamente, comprometió el propio repositorio Y te puedes imaginar lo
peligroso que es esto, ¿verdad? Porque ¿por qué? Porque el malware está siendo arrastrado a la estación de trabajo del
desarrollador. Y a partir de ahí, se está
incorporando a la compilación, y ahora le estás
dando a ese malware la capacidad de moverse
por tu entorno. Y dado
que las personas primarias que se están comprometiendo
son los desarrolladores, y si recuerdas de
lo que hablamos, los desarrolladores, tradicionalmente tienen más acceso que la gente
normal, ¿verdad? Tienen
privilegios elevados, usuario potente. Por lo que esto
les permitirá potencialmente
acceder a entornos de producción. Potencialmente podrías
obtener acceso a bases de datos, contraseñas, otros activos
críticos, ¿verdad? Existe un enorme
potencial de escalada
de acceso para el atacante que
realiza una escalada de privilegios,
que es un objetivo central de la mayoría
de los compromisos de datos Cuando el atacante se
mete en un entorno, lo primero
que quiere hacer es convertirse en el administrador, ¿verdad? Y esto es sólo para
mostrarte lo que puede pasar. La gente piensa que, Oh, el depósito de códigos podría
hacerse público. Eso es lo peor
que puede pasar. No, si no ha
asegurado su repositorio de código, el informe de código en sí puede verse comprometido y ser
utilizado para servir malware Y vamos a
hablar de todos los controles
de seguridad más adelante. Primero, quiero que
entiendas los riesgos. Y esto está muy ligado al entorno del
desarrollador. Hablamos de
esto antes, ¿verdad? Que un desarrollador necesitan
acceso porque quieren la capacidad de poder
quieren sandboxes Quieren la capacidad de hacer
girar máquinas virtuales, instalar aplicaciones,
al menos acceso elevado. No quieren ese PC
corporativo en el que no
pueden hacer nada porque necesitan la
capacidad de ejecutar código. Entonces tienen herramientas eléctricas, tienen ID con complementos. Esos plugins pueden verse
comprometidos, ¿verdad? Entonces todas esas cosas en las que
tienes que pensar. Y, por supuesto,
PreprodeEntornos. El entorno pre prod
, tendrá datos de clientes. Entonces, si hay un malware, compromete la máquina
desarrolladora, y poco a poco se empuja
hacia el entorno, el atacante podrá llegar hasta llegar
a
un entorno al que el malware
es capaz de decirle,
Mira, ahora tengo acceso
a los datos del cliente Podrás
exfiltrar esos datos. Entonces así es como se puede ver cómo se unen múltiples
cosas, el PC desarrollador
no es seguro, el barrido de origen se
está comprometiendo, su
entorno de preproducto que contiene datos de producción
completamente abiertos Todos estos se unen para comprometer realmente
su entorno. Entonces esto fue más desde la perspectiva del
desarrollador. Ahora hablemos de ataques
durante la fase de compilación. Hablamos de un
servidor de compilación antes, ¿verdad? Es una parte crítica
de CICD porque básicamente automatizan el
proceso de compilación de código,
ejecución de pruebas, preparación de
aplicaciones para su implementación Es como si el servidor de compilación
estuviera haciendo todo, ¿verdad? Y los ataques durante
la fase de compilación son bastante peligrosos porque si atacante puede obtener acceso
no autorizado o control
sobre el servidor de compilación, y realmente pueden causar
estragos en su entorno ¿Por qué? Porque las plataformas construidas suelen estar integradas con
sus repositorios de artefactos,
dónde está su código o
sus repositorios de paquetes, ¿por qué? Y pueden modificar tu construcción. Por lo que en realidad pueden atacar
estas plataformas de proyectos de ley. Tienen muchos
parámetros, ¿verdad? Así que en realidad pueden cambiarlo. Pueden usarlo para dirigir
a algún lugar que
esté comprometido. O en realidad pueden
usar la
propia plataforma de proyectos de ley para empujar su
propio código malicioso, como el que
ocurrió con los vientos solares, que hablamos en breve. O en realidad pueden usarlo para comprometer los
artefactos, ¿verdad? Por lo que la plataforma construida es una parte
muy, muy crítica
de su entorno. Y uno de los mejores
ejemplos de lo que sucede son las victorias solares. Después de esta lección,
vamos
a ver algunas lecciones más adelante, vamos a hacer el estudio de
caso de lo que sucede cuando una
plataforma construida se ve comprometida. El gran impacto
del mejor ejemplo de
eso es que la energía solar gana. El otro
muy vinculado a esto es el compromiso del gasoducto
de la CICD Hablamos del gasoducto
de la CICD. ¿Por qué? Eso automáticamente
empuja código, despliega, lo prueba. Y estos ductos son
objetivos muy, muy atractivos para los atacantes. ¿Por qué? Porque
ofrecen un camino directo al entorno de
producción de software sistema de usuario
y a los datos. Entonces quiero decir, ¿cómo
se puede comprometer? Hay múltiples formas. Es posible que tengas credenciales
inseguras. A lo mejor no has configurado correctamente los controles de acceso. Es posible que tengas herramientas vulnerables que se vean comprometidas, ¿verdad? Y recuerde, CSCDPipeline los procesos automatizados que
están utilizando para integrar, probar e Y estos pueden llevar a
graves brechas de seguridad. Y esto puede llevar a que en realidad otros clientes
también se comprometan, que vamos
a hablar en un estudio de caso llamado Cod COV Te voy a mostrar
lo que pasa. En realidad, si el ducto de la CICD se ve comprometido,
el impacto de eso Entonces estos son los dos. Entonces uno es el servidor de compilación, vamos a hacer un
estudio de caso y este. Vamos a hacer un estudio de
Kas. En breve les voy
a mostrar lo que sucede cuando ya sea
el servidor de compilación o el pipeline CICD
se vea comprometido Pero ahora mismo,
quiero que
piensen en el impacto de lo
que puede suceder. Por lo que esto abarca esta sección
en particular. Ahora vamos a
hablar del depósito de paquetes, pero como dije, no
quiero o,
como, abrumarte con
demasiada información En la siguiente lección,
vamos a
hablar del paquete llorado y ataques
específicos
que pueden apuntar a él y algunos ataques únicos
como dependencia, ataques de
confusión Cómo suceden y cuál es el impacto de esos ataques. Así que muchas gracias, y nos
vemos en la próxima.
6. Riesgos de la cadena de suministro - 4: Hola a todos. Bienvenida.
Bienvenidos a esta lección. Y ahora vamos a estar
centrándonos en el reposo del paquete. Si recuerdas tu software que está incluido en
un paquete, ¿verdad Todo el código y todo
lo que obtiene dependencias, se empaqueta en un paquete, que puede implementar en los entornos
del cliente, en sus entornos de producción Ahora, el repositorio de paquetes es donde se guardan
estos paquetes, y el informe de paquetes
en sí puede verse comprometido Entonces tal vez no has asegurado
el repositorio del paquete, ¿verdad? Le hemos dado acceso abierto. Entonces lo has configurado mal. A lo mejor te has conectado
a Internet, lo
mejor has permitido el acceso
anónimo. Estás usando
contraseñas predeterminadas y otorgando privilegios de
carga a
usuarios que pueden ser abusados. Y lo que puede pasar
es que un atacante puede obtener acceso a este
repositorio de paquetes y envenenarlo. Por lo que el repositorio de paquetes
es violado o manipulado por
actores maliciosos Entonces esto puede afectar la integridad y seguridad de toda la cadena de
suministro, ¿verdad, la
cadena de suministro de software, porque pueden empujar paquetes maliciosos, verdad? Recuerde, este es un lugar
centralizado donde se
almacenan los paquetes de software. Entonces, ¿qué puede pasar? La gente puede empujar malware. Por lo tanto, la inyección de malware, el código
malicioso se
puede agregar a los paquetes
en el repositorio. Entonces, cuando la gente lo está
descargando e integrando estos paquetes
comprometidos, el malware se convierte en parte de la aplicación o uh el robo de
credenciales, ¿verdad Tal vez los atacantes puedan robar credenciales de
los paquetes y luego usarlas para insertar otro
código no autorizado dentro de la canalización. Incluso puedes tener reemplazar paquetes
legítimos. Entonces tienes un nombre de paquete. Puedes reemplazar eso con
tu propio paquete malicioso, y aguas abajo, será
empujado a miles y
miles de personas. Y por último, ataques de
confusión de dependencia. Este es un tipo especial de ataque donde lo que hacen los atacantes
es publicar paquetes, cuyos nombres son similares a paquetes privados
internos
utilizados por la compañía. Y si el paquete público, tiene un número de versión más alto, los gestores de
paquetes podrían obtener esto en lugar
del interno, y te voy a mostrar
cómo sucede eso Es un ataque muy singular, pero
extremadamente peligroso. Pero esto es justo lo
que quería mostrarte. Y esto no es una broma. Es decir, el repo de paquetes,
sólo para darte un ejemplo. Este fue un repositorio de paquetes que
quedó comprometido el año pasado. El atacante pudo
acceder, creo que a cuatro cuentas
inactivas, y secuestraron
más de una docena de paquetes
con más de 500 millones de
instalaciones, Y básicamente
reemplazaron creo que la descripción del paquete
con su propio mensaje, y eso se
permitió comprometer, básicamente, modificar los paquetes, y se empujó cada vez más. Entonces los desarrolladores descargando
los paquetes, obtendrían el paquete
malicioso. Y solo para mostrarte
lo peligroso que es esto, gente si no estás usando algo como la autenticación
multifactor, si solo estás abriendo
tu usando contraseñas compartidas, y así es como sucedió eso Y, ya sabes, esto solo te
va a mostrar lo peligroso que es que los pers, que están completamente abiertos, que no tienen control de acceso, en realidad
podrías obtener malware. La gente piensa en Malware. Piensan en
algo que
entra en Internet o
a través del correo electrónico, ¿verdad? No se dan cuenta de que
su cadena de suministro de software, que es su paquete pers, sus plataformas construidas
que también pueden usarse para insertar código malicioso en su entorno y en el entorno de
su cliente, lo que puede causar un problema
masivo de reputación a su empresa Así que recuerda todas estas
cosas, por favor. Y ahora, entonces de lo que
quería hablar antes, confusión de
dependencia,
si recuerdas. Entonces estos son como un tipo
especial de ataque. Estos explotan cómo los administradores de
paquetes están descargando e
instalando paquetes. Entonces, lo que hace un atacante es publicar un paquete
malicioso un repositorio de paquetes públicos con el mismo nombre que un paquete
popular, que se está utilizando internamente Y lo que sucede es cuando
solicitas este paquete, si no estás configurado
tu repositorio de paquetes, lo que va a hacer es
ir
primero a Internet y verificar si hay un número de
versión más alto Entonces, suponiendo que estés usando Versión uno en
tu repositorio privado, el atacante va a poner el mismo nombre y
va a poner la versión dos Entonces el repositorio de paquetes, si
no lo has configurado correctamente, va a descargar
este paquete malicioso Entonces por eso se llama la confusión
de dependencia, ¿verdad? Estamos explotando la
forma en que funcionan estas cosas. Recuerda, tenemos repositorios públicos
y repositorios privados, ¿verdad? Lo siento. Entonces, los repositorios privados son uno que están
alojados internamente, pero es posible que tenga público como administrador de paquetes de
nodos
y todo eso, ¿verdad Entonces los públicos, los atacantes
pueden empujar rápidamente pueden averiguar cuáles son los paquetes comunes
y más populares, y pueden empujar rápidamente
muchos y muchos paquetes, paquetes maliciosos
con el mismo nombre. Y esto es muy, muy peligroso porque si
no lo has configurado correctamente, atacantes pueden crear un paquete malicioso
con el mismo nombre que un paquete legítimo y subirlo a estos
populares repositorios de paquetes Entonces, cuando un desarrollador está pidiendo una dependencia
legítima, el administrador de paquetes que va a ir va a buscar
este paquete malicioso Y esta es una gran
manera de impulsar Malware. Entonces así es como va
a quedar, ¿verdad? Tienes un
repositorio de paquetes públicos. Ahí va el atacante. Dice, Bien, estos son
los paquetes más comunes. Voy a empujar el mío
con el mismo nombre, pero voy a poner un número de versión mayor
que el actual. Versión tres, versión
cuatro, versión cinco, ¿verdad? ¿Y qué pasa? Entonces el
desarrollador va ahí. Dice, quiero paquete XYZ
al registro privado. No han configurado
este registro privado para usar únicamente los privados. Entonces, por defecto, el comportamiento
va a ir primero al repositorio
público Se va a decir y va
a buscar el paquete equivocado No va a ir a buscar
la interna. Va a decir,
Oye, tengo la versión uno en Internet,
hay la versión dos. Entonces va a dar
lo que se llama el último. Pero esta fue maliciosa. Este fue uno empujado
por el atacante. Entonces, si tiene éxito,
una confusión de dependencia y un ataque pueden tener consecuencias seriamente
estropeadas Puede infectar a todos los clientes que instalan el paquete
malicioso, y luego pueden ser atacados
porque han sido comprometidos por malware
o ransomware, y pueden
mitigarse asegurándose de
que los desarrolladores revisen y verifiquen sus
paquetes y mantengan sus dependencias actualizadas pero con las privadas, Entonces es un tipo
de ataque muy singular con el que mucha
gente no está familiarizada. Y esto es bastante peligroso
en la forma en que funciona. Así que eso envuelve este particular lo que se llama área de riesgo de seguridad de la
cadena de suministro. En la siguiente lección, voy
a hablar de un estudio de caso. Recuerden que hablamos de que
la plataforma de construcción se ve comprometida y
el pipeline de CICD Vamos a
hablar de
las venas solares y las de código CV. Entonces, pero en esta lección, que fue bastante larga, hablamos sobre los tipos de software, los riesgos de la cadena de
suministro, los diferentes
puntos de entrada de los ataques, y el impacto que puede ocurrir. Entonces con el impacto,
voy a darle más contexto al
mirar realmente los ataques reales que han ocurrido y similares
las consecuencias muy peligrosas que ocurrieron por
estos ataques. Así que
muchas gracias. Tómese el tiempo para ,
como,
volver a pasar por esta lección si es necesario. Para que tengas una
buena base, y te veré en la
siguiente lección. Gracias.
7. SolarWinds: Hola a todos. Bienvenida.
Bienvenido a esta lección, que trata sobre entender
el ataque de los vientos solistas. Seguro que debió
haber escuchado sobre el ataque de la cadena de
suministro de los vientos solares. Es uno de los ataques más devastadores que jamás
hayan ocurrido, al
menos dentro de los 21 años de trabajado en la ciberseguridad, el impacto y la cantidad de empresas que se vieron comprometidas Solar gana es fácilmente uno de los ataques cibernéticos más grandes
que jamás haya ocurrido. Es muy posible que
estés tomando este curso mío, principalmente por el ciberataque del viento
solar, voy a ser honesto, sí. Entonces esa es la razón por la que
quería hablar de los vientos solares. No se puede hablar de seguridad de la cadena de
suministro sin
hablar del
ciberataque eólico solar y
estudios de casos, y, ya sabes, realmente dar un paso
atrás y mirar algunos de estos temas
realmente ayudará a contextualizar los riesgos de seguridad de
la cadena de suministro de los que estaba hablando, porque entonces puedes
echarle un vistazo desde
la perspectiva de un incidente
real que la perspectiva de un incidente
real y sólo para tener una mejor idea de lo peligrosas que son
estas cosas, ¿verdad? Entonces, sigamos adelante. Entonces, cuando hablamos de
victorias solares, es, como dije, uno de los ataques de cadena de
suministro más devastadores de todos los tiempos. Es como reconocido, ya sabes, todos los grandes incidentes de
ciberseguridad, y realmente muestra las vulnerabilidades
que hay dentro la cadena de suministro del sofá y las consecuencias
como el impacto Los triunfos solares tuvieron un impacto global. Se extiende entre gobiernos,
organizaciones de todo el mundo, simplemente por lo común que es
el
software de viento solar, ¿verdad? Y realmente tantas OSC, miles y miles
de empresas, reevaluaron la seguridad de su cadena de
suministro y su confianza en
proveedores externos en todas las industrias Y la energía solar gana, si no
estás familiarizado, es una compañía de software de
gestión de redes ampliamente utilizada, y que fue el objetivo ataque de
la cadena de
suministro altamente sofisticado. Básicamente,
los atacantes pudieron infiltrarse el desarrollo de
software de viento solar y en el proceso de distribución, y pudieron insertar código
malicioso en
sus actualizaciones de software Entonces no fue solo un
ataque directo a las victorias solares, sino un ataque indirecto a
las miles y miles de empresas. En la que confían. Entonces la actualización maliciosa, se disfrazó como una
actualización de software legítima para ganar energía solar, y se distribuyó a miles de clientes de solar
gana, y se abrió paso furtivamente
en las redes de tantos clientes de
solar win Y es realmente un
recordatorio de lo
importante que es asegurar la cadena de suministro de software y cómo realmente necesita
seguir evaluando, seguir haciendo estas evaluaciones de
riesgos. Entonces esto es lo que se veía bien. Como te dije, solar
gana ofertas como gestión y
monitoreo de rendimiento de
ID sistema de gestión y
monitoreo de rendimiento de
ID llamado Orion, y es utilizado por
clientes de todo el mundo. Y Orion suele tener acceso a los registros y datos de
rendimiento del sistema de los clientes. Y por eso probablemente la razón por
la que los atacantes la atacaron
porque por eso se convirtió en víctima del ataque a la cadena de
suministro. Entonces, lo que hicieron fue que usaron malware
personalizado diseñado para
el ciclo de construcción de los vientos solares. Y fueron capaces de
reemplazar los archivos. Algunas personas dicen
como milisegundos, y básicamente fueron capaces de
reemplazar los archivos con sus
propias actualizaciones maliciosas Y hubo un
ataque muy,
muy sofisticado , como lo
hicieron, ¿verdad? Se llamaba la malway
se llamaba Sunspot, y permitía que los hackers básicamente
monitorearan El entorno de
desarrollo de los vientos solares. Y cada vez que
estarían empujando sus facturas, las reemplazarían con
su propia actualización maliciosa. Entonces básicamente, era una puerta trasera. Y esta puerta trasera, cuando las actualizaciones fueron empujadas
la actualización maliciosa, ahora tenían acceso a
miles y miles de clientes porque
pudieron colarse en otros
clientes porque habían puesto su propia actualización maliciosa
dentro de la actualización de victorias solares Así que las victorias solares les ayudaron a
distribuir este malware, ¿verdad? Y puedes entender
por qué Slewns fue un objetivo
tan prometedor para este tipo de ataque a la
cadena de suministro, ¿verdad ¿Por qué
posiblemente serían así? Bueno, porque
honestamente, como dije, muchas empresas multinacionales y agencias
gubernamentales
utilizan el software Oon. Todo lo que los hackers necesitaban era instalar esta actualización
maliciosa, y Solewns la estaría
distribuyendo, ¿verdad? Y debido a que las empresas
están confiando ellos, los estarían
instalando. Entonces fue, como, realmente
hermoso en el camino no hermoso por el
daño que sucedió, sino realmente hermoso en
la forma en que fue diseñado. Se podía ver
lo inteligentes eran
estos tipos, ¿verdad? ¿Y qué pasó después de eso? Una empresa de seguridad,
creo que fue Frey. Detectaron este malware que se estaba propagando
a los clientes, y pudieron identificar el paquete de actualización sunburst Identificaron en K este paquete de
solvins ha sido
comprometido, Y una vez detectados,
inmediatamente emitieron esta actualización, y varios clientes
pudieron detectar el mismo comportamiento
sucediendo en su enami Y así se dieron cuenta de lo
malo que era el spread, ¿verdad? Había infectado a miles y miles de clientes por ellos. Y Solns sí lanzó hot fixes
rápidos para
eliminar esta puerta trasera Pero, ya sabes, quiero decir, alrededor creo que 18,000 clientes de vides solares y
aplicaron la actualización Sunburst, que luego permitió a los
atacantes
acceder de forma remota a los datos de sus clientes Y, ya sabes, teníamos, creo que el Departamento de
Salud de Estados Unidos, Tesorería y Estado, todos ellos estaban infectados,
grandes nombres, ya sabes, como las grandes empresas tecnológicas, todas
ellas se vieron afectadas
por el malware. Y el objetivo de esto es porque la forma en que
pudieron
difundirlo, mostró el punto ciego de
confiar en las actualizaciones de software, y realmente llevó a que no solo vides solares
sino a otras empresas echaran un vistazo al proceso de
reconstrucción Si eres una empresa que está distribuyendo software a
otras empresas, ¿verdad? Y estás
emitiendo actualizaciones automáticamente. Realmente necesitas
pensar en ¿qué pasa si hay un
malware dentro de esto? ¿Cómo me aseguro de
que no me pase a mí? Y ese es el punto de
mirar este estudio de caso. Y eso es lo que
pasó después de esto. Así que teníamos tantas
empresas echando un vistazo a sus facturas de software, como, ¿cómo me aseguro de que no
tengo a alguien colándose Y aquí es donde
empezó a salir a la luz el concepto de construcciones
reproducibles, que discutiremos en breve Pero solo quería
mostrarte el impacto. Teníamos, como, un gobierno de
Biden, emitieron una orden
ejecutiva y mejoraron la
ciberseguridad de la nación Se puede ver la
fecha 12 de mayo de 2021, y tenían un requisito
específico sobre seguridad de la
cadena de suministro de software. Dijeron que
mencionaron el hecho de que
este tipo de software, no
tienen transparencia. No sabemos qué pasa si viene
Malware, y realmente necesitamos poner
controles para asegurarnos de que la
seguridad de la cadena de suministro del software está asegurada, ¿verdad? Y lo más, como, lo impactante fue
en la jugada Landmark, la Securities and
Exchange Commission, SEC, en realidad cobró a la CSO
de victorias solares con fraude y fallas de control
interno relacionadas con las prácticas de
ciberseguridad de
la compañía Dijeron que
compraron cargos que usted había equivocado lo
seguro que era el solar gana Entonces ellos en realidad
compraron estos. Dijeron que había
engañado a los inversionistas sobre las prácticas de
ciberseguridad de la compañía No había dado a conocer los
riesgos y el control inadecuado. Entonces, básicamente, había exagerado
lo asegurados que estaban, y no había revelado
todos los riesgos Y eso es que fue bastante como un cambio significativo en la forma en que la
gente ve la ciberseguridad Ahora las OSC se dan cuenta de que
en realidad son responsables, ya
sabes, no solo con multas
sino en realidad tiempo en la cárcel Y va a evaluar las OSC realmente
tuvieron que dar un paso atrás. Y es por eso que la seguridad de la cadena
de suministro de software se
ha vuelto tan, tan
prominente hoy en día. Y espero ser capaz de
hacerte entender
lo grande que
fue la victoria solar. Ahora, ¿cómo proteger? Esa es una
pregunta de 1.000.000, ¿verdad? ¿Cómo te aseguras de
que tu empresa no se convierta en la
siguiente, digamos, la solar gana? Ahora, desafortunadamente, muchas buenas prácticas
convencionales de buenas prácticas
convencionales de seguridad no pueden contrarrestar
este tipo de ataques. Al igual que, ¿qué dice la gente que solo instaló
versiones firmadas, ya sabes, actualizaciones de
software firmadas
digitalmente que vienen de la energía solar gana No va a ayudar porque
el software es signo. Viene de la empresa
legítima. No es como si un atacante
la estuviera metiendo a escondidas. Viene de la compañía de
confianza, ¿verdad? Actualiza tu software a la última versión, como dirá la
gente, ¿verdad? Porque el software actualizado era el que era malicioso. Y fue parte del proceso de construcción
válido. Entonces ahí es donde comenzó a entrar
el problema. Ni siquiera se puede decir,
revisar el código fuente porque estaban comprometiendo
el proceso de compilación, ¿verdad? Y así, algunas de las
cosas clave que puedes hacer es, junto con tus buenas prácticas de
seguridad como monitoreo y endurecimiento, cierto, asegurándote de que tienes
controles que monitoreen el comportamiento, las organizaciones realmente
necesitan endurecer su proceso de construcción contra este
tipo de ataques, ¿verdad Y necesitan asegurarse de que el entorno de construcción
no pueda verse comprometido. Se han asegurado de que
hablaremos
más de esto cuando hablemos de asegurar la cadena de suministro de software. Pero el entorno de construcción
necesita ser asegurado. Debe asegurarse de
que la gente no pueda simplemente comprometer el medio ambiente e insertar sus propias actualizaciones
maliciosas, y hay que estar monitoreando. Y las dos
cosas más importantes que puede hacer son construcciones reproducibles
verificadas y las listas de materiales de
software Voy a entrar en detalles sobre sus
listas de materiales de software, pero la
contramedida más fuerte que puede tener se llama
compilación reproducible, que es una compilación
que siempre produce las mismas salidas para que se
puedan verificar los resultados de compilación Entonces, básicamente, compilación reproducible
verificada es donde alguien independiente puede producir una compilación a partir
del código fuente y verificar que los resultados de compilación provienen del mismo
código fuente que está reclamando Casi, yo diría que el 99% del software hoy en día no
es así. Pero en el caso de los vientos solares,
¿qué habría pasado? Al igual que, ¿cómo sería la compilación
reproducible verificada? Apenas por el nombre
que puedes ver,
puedes verificarlo y
podrás reproducirlo. Entonces, si tienes acceso tanto
al
código fuente como a la compilación. ¿Qué hacen las facturas
reproducibles verificadas? Básicamente te dan una contramedida
muy, muy fuerte
contra ataques como ins
solares donde los
binarios no coinciden con
el código fuente ¿Por qué? Porque un atacante ha insertado código malicioso en un binario, ¿verdad? Porque en el caso
de las venas solares, atacan al binario,
no al código fuente. Entonces, una de las ventajas de las construcciones
reproducibles es
que cuando esas dos construcciones ocurren, puedes construirlas de
forma independiente, y ambas producirán el mismo artefacto poco a poco Y te dará
esa confianza de
que no se
inyectó malware en esto. Y esta es toda la
motivación detrás de este concepto. Y lo que hubiera
pasado en los ins solares si victorias
solares hubieran implementado facturas
reproducibles, habría requerido que generaran un buen binario
a partir de la fuente y
lo compararan con el binario distribuido Y no coincidiría, ¿verdad? Entonces esta discrepancia habría sido
introducida por la inserción
del código malicioso, y se habría detectado porque cuando están
distribuyendo el binario, no habría coincidido con la compilación reproducible verificada Y esto podría haber
alertado a los desarrolladores la presencia de cambios
no autorizados que,
oye, el proceso de compilación se
ha visto comprometido Hay algo extra agregado al binario, que antes no
estaba ahí. ¿Es como infalible, al 100%?
Absolutamente no. Porque recuerden, los atacantes ya
estaban dentro del
ambiente, ¿verdad? Entonces necesitas otros controles
de seguridad también. Pero este tipo de construcción verificada y
reproducible,
esto te da un tipo de
control
muy, muy fuerte contra ella Voy a poner
el enlace también a todo
el sitio web que
pretende este tipo de control Pero recuerda que si
estás distribuyendo actualizaciones a miles de clientes y necesitas este
tipo de verificación, el
cinturón reproducible verificado es un control muy, muy fuerte
contra esto Entonces espero que esto te haya sido
útil. Dimos un paso atrás y echamos un fuerte vistazo al ataque de los vientos
solares. Ahora, vamos
a echar un vistazo otro ataque y
ver cómo sucedió eso y fue un tipo diferente
de ataque de los vientos solares. Pero solo para
darle más contexto sobre cómo ocurren estos ataques, gracias, y los
veré en la siguiente lección.
8. Codecov: Es más Hola a todos. Bienvenidos a esta lección.
Y ahora continuando desde la anterior donde echamos un vistazo a los vientos solares. Ahora vamos a
otro reciente,
que es dov attack Ahora bien, los vientos solares,
si recuerdas, comprometen el proceso de
construcción, ¿verdad? Los atacantes
pudieron comprometer el proceso de compilación
e inyectar malware. Con este, se
trata más del pipeline de la CICD. Si no estás familiarizado
con Codkov y espero que esté pronunciando el nombre si no
se enojan conmigo Pero sí, es una herramienta de cobertura de
código. ¿Qué significa eso? Básicamente, la comprobación de
cuánto de tu aplicación
se está probando, ¿sabes? Al igual que cuando estás construyendo aplicaciones
modernas cuando usamos CICE,
usamos pruebas automatizadas,
¿verdad? Hablamos de esto antes. Y queremos asegurarnos de que cada línea de código ha
sido probada, bien, y cada FOG y esto requiere bastante marco de
prueba maduro. Aquí es donde entra en juego Cod Cov, y puede ayudarte a saber
qué líneas de código no están siendo cubiertas
en tu entorno de CI Y así es como
comprometen comprometen éste lo que les permitió comprometer otros
entornos también. Ahora bien, si recuerdas el viento solar, victorias
solares fueron más apuntadas
y hacia el espionaje contra agencias gubernamentales y grandes corporaciones, ¿verdad Tenía un claro motivo geopolítico, como un ataque estado-nación Esta es más como una
amplia brecha de seguridad que afectó indiscriminadamente a una amplia gama de
empresas No les
importaba quién estaba siendo comprometido. Y estaban
enfocados en robar información de los entornos de
desarrollo de Soffe Oh, de esto es de lo que estamos
hablando ahora. El ataque de Code Cv,
fue descubierto en abril de 2021, si recuerdo. Sí, era como una playa de seguridad
masiva. Y como dije, esta es una herramienta de cobertura de
código muy popular utilizada por los desarrolladores de software para evaluar qué tan efectivas son
sus pruebas. Y se integra con diversos sistemas de control
virgen. Genera reportes para que
sepas lo bien las pruebas de software están cubriendo
tu base de código, ¿verdad? Entonces, básicamente, los atacantes, obtuvieron
acceso no autorizado a los sistemas Code CoF Cómo explotaron
nuestra vulnerabilidad. Creo que en su creación de imagen
Docker, no
necesitamos conocer los detalles de
Docker Pero básicamente, modificaron
el guión del cargador de Bash. Voy a ver
detalles de eso. Lo que les permitió hacer les
permitió
exportar secretamente información sensible de los clientes de Cod C, ¿verdad? A partir de ahí, específicamente desde los entornos CI, entornos de
integración continua. Y lo que esta información, credenciales, ID de usuario, contraseñas, claves
simbólicas y otros datos que podrían usar para otorgar mayor acceso
y no autorizado. Pasó desapercibido durante
varios meses, creo, desde el 31 de enero de 2021
hasta abril de 2021. Y cualquiera que descargara el guión del
cargador de Bash comprometido, básicamente, expuso sin saberlo
su Creo que afectó a
unos 29,000 clientes, grandes nombres de la
industria, ¿sabes? Y nuevamente, como siempre, todos se despertaron ante los ataques de la cadena de
suministro. Lo siento, y todos se
despertaron ante los ataques de la cadena de suministro, y de repente se dieron cuenta lo críticas que son
estas cosas. Y Kotov sí lo
notificó a los usuarios afectados y ellos revocaron y emitieron
las llaves y todo, y acordaron que se auditara
su entorno Pero si le echas un vistazo, así es como básicamente se
veía, ¿verdad? Entonces, centrémonos en si
recuerdas el entorno CI, un
entorno de integración continua. Podemos hacer mucha automatización
poderosa aquí para probar nuestra
aplicación, ¿verdad? Y también confías en muchas cosas
externas, ¿verdad? Bases de datos, sistemas de pago, infraestructura
en la nube. Cuando esté haciendo
las pruebas, y todos estos componentes deben ser accedidos desde la canalización para que puedan construir
y probar la aplicación. Entonces, básicamente,
su canalización de CI necesita tener acceso a qué secretos y credenciales
para que puedan acceder. Y normalmente, ojalá, si estás
construyendo un entorno de CI, deberías usar
infraestructura de puesta en escena , no byte de
producción, pero basado en mi propia experiencia, es muy común que
se usen credenciales de
producción porque la
gente quiere
asegurarse de que están haciendo
las pruebas correctamente, y las pruebas cubren tanto
como sea posible. Entonces, lamentablemente, muchas veces esa información
puede suceder. Por lo que es muy probable que el entorno CI tenga acceso a información muy
sensible. Entonces atacando a Kotkov y
esto es lo que hicieron, ¿verdad? Ellos infectaron el malware, comprometieron
la herramienta de prueba. Tienen acceso a
todas las credenciales. Dentro del entorno CI
para todos los clientes de Cdf. Y básicamente, si recuerdas, comprometieron un guión de Bash, que es solo un conjunto
de instrucciones sobre lo que escribirías si alguna vez
has hecho
terminal o Bash, pero escrito de manera
programativa Agregaron una sola
línea de código, que era enviar todas sus variables
de
entorno desde el CI al servidor remoto del
atacante. Entiendes que básicamente están exfiltando
silenciosamente Y ahora puedes entender si tienen alrededor de
23 mil clientes, cualquiera que estuviera usando la versión
comprometida de
Cod Cov entre el
31 de enero y el 1 de abril se
habría visto Y las grandes corporaciones
se vieron afectadas, y de hecho publicaron
básicamente documentos para sus clientes
sobre cómo
recuperarse de este ataque. Y qué hacen, qué
hicieron después de haberlo comprometido. Por lo que no los
atacaron directamente. Podrían haber realizado múltiples ataques a
partir de ahí, ¿verdad? Pero lo que hicieron fue
que en realidad comprometieron los repositorios de código fuente porque obtuvieron las
credenciales, ¿verdad La fuente. Y
pudieron acceder entonces a sus repos de código fuente Y pudieron
encontrar porque esos repositos podrían tener realmente credenciales de
producción Para que veas cómo está en cascada este
ataque, ¿verdad? Primero, comprometieron a Kotkov. Obtuvieron las credenciales a los repositos de código fuente de los clientes Ellos comprometieron esos repositos. Obtuvieron acceso a la producción. Y se habían levantado incluso
notaron que habían notado la actividad sospechosa
de otros repositorios privados Estaban siendo clonados a
algunos usuarios no autorizados, y solo muestra lo
simple que era, ¿verdad? KotkvuUsa credenciales Git
robadas, accede a repositorios privados, usa
esas credenciales robadas y luego puedes comenzar a
escanearlas escanearlas Solo para mostrarte lo bellamente simple que fue este ataque y cómo fueron capaces de comprometer a
tantos uh, clientes usando esto. Nuevamente, como mencioné,
tuvo un impacto global. Cantidad masiva de clientes, estaban rotando
sus secretos, sus depósitos de código fuente y atacantes pudieron
acceder a depósitos no autorizados, y containterales código
fuente, credenciales internas,
desafortunadamente estaban rotando
sus secretos,
sus depósitos de código fuente y los
atacantes pudieron
acceder a depósitos no autorizados,
y containterales código
fuente, credenciales internas,
desafortunadamente. Nuevamente, ahora tienes una mejor
idea de lo que se puede hacer. Por supuesto, es diferente
de los vientos solares, donde el entorno de construcción
se vio comprometido. Pero aquí, de nuevo, hay que hacer seguridad alarmador
del medio ambiente No puedo lo suficientemente estresante, tienes que asegurarte de que tu
entorno sea seguro Mantenga limpios sus
repositos de código fuente. No pongas credenciales
ahí en tu reposo. Si alguien es
capaz de comprometerlos, puede usarlo como punto de salto en tu entorno, ¿verdad? Poner en filtración de datos
y controles de fugas. ¿Cómo saber si alguien está filtrando
silenciosamente los datos en todo el Incluso puede endurecer
sus repositorios de código fuente a través de la autenticación multifactor
y Entonces, si sabes que las solicitudes solo
vienen de
un área en particular, en realidad
puedes poner
restricciones de IP, ¿verdad? Entonces, aunque cuenten con
las credenciales, no
podrán acceder a ella. Endurecimiento de
la seguridad de los ductos CICD, asegurándose de que solo tengan
ese acceso que se necesita No quieres
darles
credenciales de administrador en
todo el entorno, ¿verdad? Y por supuesto, evitando las
credenciales codificadas. Entonces este fue, nuevamente,
otro estudio clave, otro entorno
que se había visto comprometido debido a un ataque a la cadena de
suministro, y espero que ahora hayan visto una imagen
diferente. Elegí deliberadamente
este porque es diferente de cómo se comprometieron
los solares. Entonces ahora tienes una buena idea, y espero que ahora hayas establecido el escenario para entender cómo podemos hacerlo para asegurarlo. Se tiene una buena
idea de los riesgos, y dentro del contexto
de los ataques reales, ve cómo se materializan esos
riesgos Así que ahora podemos pasar
a la siguiente lección, que trata de
asegurar realmente la cadena de
suministro de software. Ahora podemos pasar
a la parte buena, que en realidad es asegurar
y mitigar estos riesgos Así que muchas gracias, y nos vemos en
la siguiente lección.
9. Crowdstrike: Hola a todos. Bienvenida. Bienvenido a
esta nueva lección que acabo de subir con respecto a
la interrupción de CrowdStrike Entonces, a menos que me refiero, si no
estás usando TI o no estás usando ningún sistema en absoluto, habrías escuchado sobre
la interrupción de CrowdStrike, que ocurrió
este año en 2024 Cloud Strike es una empresa muy, muy popular como una empresa de
soluciones de seguridad. Es decir, dan sus
productos exclusivamente a empresas y
grandes organizaciones. Son muy, muy famosos en
el mundo de la ciberseguridad. Desafortunadamente, se vuelven
como un nombre familiar. Ahora todo el mundo los conoce
por este incidente. Y básicamente, poner a
pesar de que esto
no es como un
incidente de ciberseguridad en el sentido, nadie
lo comprometió, pero sí tuvo un impacto masivo masivo
en la cadena de suministro Y es muy importante. No podría hablar sobre la cadena de suministro de
software o los riesgos de seguridad de la cadena de suministro sin discutir
sobre Cloud Strike. Ahora bien, si no estás
familiarizado CoudStrike, básicamente
tienen
un componente llamado CrowdStrike.
Es como un sensor. Utiliza IA para proteger, entornos de
clientes, ya sabes, identificando y protegiendo
contra las últimas amenazas. Y en pocas palabras, básicamente como en 2024, introdujeron una
nueva actualización, derecho, que básicamente el nuevo sensor no
pudo manejar
y se estrelló Y dado lo cerca se encuentra
el sensor CrowdStrike del sistema operativo Windows, resultó en que todos los
sistemas se estrellaran y una interrupción masiva masiva a
nivel mundial que afectó a casi todas las
industrias en todo Millones y millones de
puntos finales se vieron afectados, ¿verdad? Y a esto se le ha denominado la mayor disrupción
de identificación de todos los tiempos o una de las creo que es la más grande porque simplemente por la
naturaleza y cómo sucedió Ya
te hablé de rodseg, es una empresa de soluciones de
seguridad muy, muy popular Millones de empresas
lo han utilizado , y es una buena compañía. Desafortunadamente, el nombre se
ha vuelto algo así como arrastrado por el barro a
causa de este incidente Pero sin duda es una compañía muy
buena, una empresa de
seguridad
muy, muy, como, madura. Pero desafortunadamente, la actualización de software
defectuosa. Yo conduje a esa
pantalla azul de la muerte. Es como un bucle en las máquinas
Windows que hace que se
estrellen repetidamente. Y a pesar de que las multitudes
desplegaron la solución, el impacto en todo el
mundo fue masivo Y como dije,
literalmente, aeropuertos, puertos, tomemos un ejemplo,
qué tipo de cosas pasan. Los aeropuertos se vieron impactados. Si te viajabas en algún momento, tienes mis simpatías Verá imágenes de, como, ya
sabes, en todos los ámbitos, aeropuertos atascados,
miles de vuelos
retrasados , puertos de
envío afectados,
supermercados, hospitales,
vivo en el Reino Unido,
y el NHS envió como un comunicado diciendo
que no son capaces atender
a los clientes en este momento pacientes debido al
impacto empresas de identificación, oficinas
gubernamentales, y así encendido. Quiero decir, en todo el
mundo, grandes cierres, demoras estaban ocurriendo, miles de vuelos
como un lateral. Y básicamente, muestra la naturaleza interconectada de
la cadena de suministro de software. Y aunque
la parte deslumbrante, esto no es como un ataque. Fue solo un error, pero mostró el impacto
que puede suceder, y esto es solo un ejemplo. Quiero decir, estoy seguro de que lo
habrías visto, ¿verdad? Pero solo muestra lo peligrosas son
las dependencias en todo el mundo con respecto a este
tipo de software, ¿verdad Entonces los globales como
dije, hospitales, negocios
australianos,
dijeron que tenían una factura de daños de alrededor de
mil millones, ¿verdad? Y bancos, medios de comunicación, NHS. Entonces el impacto en todo el
mundo fue increíble. Pero es muy, muy importante separar el hecho
de la hipérbole Y no me gusta esto la manera muchas
veces que fue fraseado Y cómo la gente empezó a decir
que era un ciberataque. Sí tuvo un
impacto cibernético en
la disponibilidad, claro, y no fue
como un ataque de un delincuente. Y sí emitieron un reporte de causa raíz,
que se puede ver. Y sí mencionaron
cómo sucedió. Básicamente, el censor. Fue como esperar, creo, alrededor de 20 campos de entrada, pero tenía la última
actualización en 21 campos de entrada, y el desajuste de conteo es
lo que provocó un bloqueo global. Y debido a que el intérprete
esperaba 20 valores, y cuando empezó
a acceder al 21, produjo un anuncio
de memoria fuera de límites Ya sabes, esas cosas. Y debido a que está tan
estrechamente integrado con el código de Windows,
cuando se estrelló, derribó
todo el sistema operativo, y la pantalla azul
parpadeaba en todo el mundo, en supermercados, aeropuertos, en todas partes que se
te ocurra, básicamente estaba parpadeando
w se reduce a, faltaban
pruebas adecuadas para las actualizaciones de los sensores Pasó por alto sus procesos
novedosos. La prueba no fue un detigores. Y mucha gente empezó a decir que esto
ya se podía explotar. Y recomendaría leer las entradas del blog de CrowdStrike
en las que abordaron, y refutaron las afirmaciones sobre
el sensor de seguridad Falcons pesar de que se trataba de un bloqueo de memoria fuera
de límites, se determinó que no
era explotable para una escalada
previa o ejecución remota
de código
a escalada
previa o ejecución remota Y dieron un análisis detallado de causa
raíz que incluso este bug no
permite ninguna ejecución de programa, y mencionaron los otros controles que
tenían como
la colocación de
certificados, validación de
suma de comprobación, control de
acceso
es
detección anti manipulación, es
detección anti manipulación Y demostraron que
voy a vincular el informe aquí, el blog aquí, y
definitivamente
te recomendaré que lo leas, porque si vas a estar
analizando estas situaciones, asegúrate de que
lo estés analizando correctamente y no estés metiendo cosas que
no existían en ese momento. Y CoudsTAK han afirmado el compromiso con la seguridad, y mencionaron que
su programa de recompensas de errores, el compromiso con la seguridad,
y mencionaron que
su programa de recompensas de errores,
también han mejorado. Pero las lecciones que hay
que aprender de este incidente son
muy, muy importantes. Entonces solo para ser muy, muy claro, atacante, aunque
esto no fue un ataque, sino que los atacantes aprenderán
de este incidente. Ellos han visto lo dañino que fue
este ataque el impacto. Entonces sin duda puedes imaginar atacantes se han
interesado en este ataque, y pensarán en
cómo pueden incluso un mayor impacto la próxima vez
y ganar algo de dinero con él. Si eres un proveedor de soluciones. Eso es como CrowdStrike, le das algún agente, algún software a la empresa Es bueno
mirar tus procesos de prueba. Piensa en este
tipo de resiliencia. ¿Qué pasa si tu
punto final está sentado muy cerca del kernel de Windows y pasa algo, verdad? Hacer una implementación de fase. No hagas un enfoque del big bang. No puedo creer que
tenga que decir esto, pero esto simplemente se nota bien. No es necesario hacer una implementación Big
Bang, hacerlo en fases y tener auditorías
independientes realizadas
de todo su proceso. CrowdStrike, creo que
se involucran con dos empresas separadas para hacer una evaluación completa de sus prácticas de
desarrollo de software,
las pruebas solo para asegurarse que no tienen
puntos ciegos Y desde la
perspectiva del cliente, si eres alguien que está usando un software como
RoudStrik En primer lugar,
recomendaría eliminar la
dependencia
excesiva de recomendaría eliminar dependencia
excesiva Si tienes un
proveedor que está haciendo todo y algo
le sucede a ese vendedor, vas a estar en
grandes problemas, ¿verdad? Piense en este escenario y agréguelo a su libro de estrategias
de recuperación ante desastres Pero tengo que ser muy claro. Este tipo de escenarios muy
pocas personas pueden predecir. Fue como un incidente del
Cisne Negro, ¿verdad? Como algo
que sucede una vez cada dos, tres décadas. Pero yo recomendaría
pensar en cosas como las copias de seguridad en la
nube o tener
como un escritorio virtual, que es una imagen completamente
separada de tus
escritorios normales, ¿verdad? Entonces, si pasa algo,
si hay un caso
mayor, mayor, podrás recuperarte
al escritorio Cloud. Y esto es algo completamente así que es aire separado de
tu red regular No cuenta con
los mismos agentes. Cuenta con diferentes agentes. Podría costar más, pero
luego en tal incidente, podrás
tener completamente creada
una imagen separada en la que tu personal
podrá retomar al menos actividades
limitadas
porque muchas empresas, estaban completamente cortadas. Los servidores estaban caídos, pero
incluso los escritorios normales están caídos porque Cloud Stoke estaba ejecutando en todas partes, Así que piensa en esto teniendo otra imagen en la que
puedas desplegar y que
puedas poner en marcha, que está separada de
tus imágenes normales y que no se verá
impactada por los mismos problemas. Entonces estas eran las
cosas de las que quería hablar
a todos, solo para mostrarte
porque CrowdSTK fue como un incidente masivo Aún se está desplegando. Están saliendo muchas
noticias. Pero piense en estos incidentes, especialmente cuando esté
pensando en asegurar su software para aplicar la cadena. Muchas gracias. Te
veré en la siguiente lección.
10. Cómo proteger la cadena de suministro - 1: Hola a todos. Bienvenida.
Bienvenido a esta lección, que es parte de una lección de
varias partes, que va a ser sobre asegurar la cadena de
suministro de software. Ahora, a estas alturas, espero que tenga una buena idea de lo que es la cadena de suministro de
software. Tienes una buena idea de
los riesgos que pueden ocurrir. Has visto ataques reales y cómo se vieron comprometidos, ¿verdad? Entonces ahora vamos
a estar buscando implementar controles dentro de
la cadena de suministro de software. Vamos a estar analizando los controles y prácticas de
seguridad, algunos de los errores comunes
que cometen las personas cuando están comenzando en su cadena de suministro de
software, su viaje de
seguridad. Y luego vamos a ver algunos estándares y
marcos también, que puede aprovechar
para obtener el mejor beneficio para cuando está construyendo un programa de
seguridad de la cadena de suministro, no
necesita
construir desde cero w. Puede aprovechar
lo que ya tiene. Entonces, si le echas un vistazo, esto
es lo que discutimos anteriormente. ¿Recuerdas? Este era
el entorno con los riesgos de que tienes
un entorno de desarrollador, que puede quedar comprometido. Tienes código inseguro, la plataforma de compilación se
ve comprometida, el repositorio de código fuente,
las dependencias, no
podrías estar haciendo pruebas de
seguridad del Tiene una violación de datos en
el entorno de preprod, e incluso su
entorno de producción puede verse comprometido Entonces aquí es donde
entra en juego la seguridad de la cadena de
suministro de software para básicamente asegurar
todos estos riesgos, ¿verdad? Y si recuerdas hace mucho tiempo
cuando iniciamos el curso, hablamos sobre la seguridad de la cadena
de suministro de software, ¿verdad? Básicamente se trata de garantizar la integridad,
seguridad, disponibilidad, confiabilidad de todos
los componentes y procesos que están involucrados. En su desarrollo,
distribución y mantenimiento de software. Quieres
asegurarte de que nadie se meta con tu software,
nadie lo maneje. Y muy, muy importante cuando hablamos de una cadena de suministro, no solo estamos hablando del código fuente directo, ¿verdad? También estamos hablando de bibliotecas de
terceros, herramientas y servicios y la
infraestructura porque puedo ver muchas veces a veces no
es su infraestructura la
que está recortando el compromiso. Son los vendedores
o los proveedores. Entonces, ¿cómo asegurarse de que su
programa de seguridad de la cadena de suministro lo cubra todo? Entonces esto es lo que
hay que tener en cuenta. Y cuáles son
lamentablemente algunos de los errores comunes
que comete la gente que siempre me gusta
me da dolor de cabeza cuando
hablo con los clientes, la seguridad de la cadena de
suministro. ¿Qué no es?
No es una herramienta o producto. Por favor. Cualquiera que te diga que cualquier proveedor que
acuda a ti y te diga, Compra mi producto,
y tendrás software de seguridad en la cadena de suministro,
eso es completamente falso Te va a ayudar. Sin duda, te va
a ayudar, pero no lo es. Es parte de la seguridad de la cadena de
suministro de software, no el objetivo final. ¿Bien? No puede automáticamente simplemente convertirse en su cadena
de suministro de software
no se vuelve segura porque ha
comprado una solución por millones de dólares
y la implementó. No es una certificación. Cualquiera dice que use esta
lista de verificación o use esta cosa, y ahora su
cadena de suministro está asegurada. Nuevamente, no es así como funciona. No es una lista de
verificación de proveedores, también. Algunas personas, lo que
hacen es hacer una evaluación de
riesgos de proveedores, y piensan que ahora su cadena de suministro de
software es segura. Y tampoco es una actividad de
una sola vez. Es algo que hay que seguir evaluando
riesgos continuamente. Y es Last one
is myF habilitando MFA. Nuevamente, no hay nada
malo en habilitar MFA. Es una parte muy importante de la seguridad
del suministro de software. Pero la gente piensa
porque ya hemos habilitado MFA ahora nuestro
entorno es seguro No tengo idea de cómo ocurre
eso, pero por favor no cometas
este error, ¿verdad? Entonces, como dije, piensa la definición que te
hablé antes,
ésta, tenlo
en mente y no confundas con
estos conceptos erróneos Y cuando hablamos asegurar la cadena de
suministro de software, estamos hablando de
múltiples controles, ¿verdad? Y esto es en lo que me voy a centrar en estas lecciones. Vamos a hablar sobre prácticas de codificación
segura, lo que puede hacer, componentes de
terceros, endurecimiento de su entorno, seguridad de canalización
CICD, pruebas y escaneo de seguridad
reales, las construcciones
de software de material, L BOM, si no está familiarizado, y, por supuesto, la administración de proveedores
West Todas estas cosas se
unen para una seguridad efectiva de la cadena de
suministro de software, y luego vamos
a ver cómo crear un
programa real también. Entonces todos estos artículos
voy a estar cubriendo. No te voy a bombardear
con información. Vamos a ir paso a
construir tu entorno, ¿verdad? Entonces, al final, tu entorno se
va a quedar así. Vas a tener
controles en múltiples niveles, y luego vas a tener
un programa adecuado funcionando, lo que asegura que
todas estas cosas
estén siendo atendidas
y evaluadas de riesgos. Entonces como dije, lo
vamos a hacer a pasos. Te veré en la
siguiente lección,
comenzaremos a
sumergirnos profundamente en estos controles. Muchas gracias, y nos
vemos en la siguiente lección.
11. Cómo proteger la cadena de suministro - 2: Hola a todos. Bienvenida.
Bienvenidos de nuevo a la lección. Y continuamos
nuestra lección anterior donde estamos
hablando de asegurar la cadena de suministro y los controles de seguridad,
podemos implementarla. Entonces, si recuerdas, te mostré estos controles básicos que hay prácticas de
codificación seguras, componentes de
terceros, entornos de
acaparamiento, ductos
CICD, ductos
CICD Todos ellos, vamos a ir uno por uno y
echarle un vistazo. Entonces, sigamos adelante. Y si recuerdas, te
mostré el diagrama también así es si antes teníamos los riesgos
que aparecían en este diagrama, pero si pones en los controles, estos controles que estás
viendo en el diagrama, esos riesgos se mitigan Entonces comencemos con
el primero, que es la codificación segura. Si recuerdas,
hablamos de los riesgos, ¿verdad? Y dije que
el código inseguro, esa es la raíz de todo mal Así que la codificación segura, es por eso que
tenemos que discutirla primero. codificación segura en el contexto de seguridad de la cadena de
suministro se refiere a
los desarrolladores que
desarrollan software de una manera que se asegura de que no haya vulnerabilidades presentes en el código en ningún
momento. ¿Bien? Y eso
requiere controles, tanto de conciencia como de controles
técnicos, ¿verdad? Porque recuerda que hay múltiples formas en
las que se pueden
introducir vulnerabilidades. Así que vamos a hablar
sobre capacitación en código seguro y cómo integrar comentarios de
seguridad
en la propia identificación, que es una parte crítica que mucha gente
se pierde. Vamos a hablar
sobre las formas en pueden ocurrir las revisiones de código
seguro. Y, por supuesto, las
pruebas de seguridad del código que se presenta el
SAST y el polvo Si has estado trabajando
en ciberseguridad, estoy seguro de que estás
familiarizado con esto Entonces primero, comencemos con
el entrenamiento de código seguro. Seguridad La conciencia
del código inseguro es un comienzo muy, muy, muy Tienes que informar a
tus desarrolladores sobre el código inseguro y, como, los peligros del mismo, ¿verdad Hay muchos, muchos buenos
entrenamientos disponibles. OS top ten es el referente de
la industria. Estoy seguro de que si estás
en ciberseguridad, ya
debes haber oído hablar
de ella Así que educarlos, contarles
sobre entrenamientos como este, mostrarles,
hablarles de las inseguridades,
pueden ser, pero muy,
muy importantes Por favor, no lo hagas
muerte por PowerPoint, que es lo que me refiero como cuando les
das como un documento de PowerPoint de 200
páginas. Créeme, nadie
va a recordar eso. Muéstrales, en realidad
muéstrales
trozos de código inseguros y muéstrales cuáles son
las vulnerabilidades Muéstrales que si
lo arreglas dentro del propio código, cuánto tiempo y esfuerzo se ahorra a diferencia de que
alguien
lo descubra más tarde y luego
lo arregle y la cantidad de tiempo
que se desperdicia, ¿verdad? Entonces hay muchos, muchos, muy buenos entrenamientos disponibles
sobre código inseguro,
en OVA, cosas como inyección
SQL, scripting de
sitios
cruzados, todas buenos entrenamientos disponibles
sobre código inseguro,
en OVA, cosas como inyección
SQL, scripting de
sitios
cruzados, todas esas cosas. Así
que hazles conciencia. Pero en un punto muy, muy
importante, y aquí es donde la
gente te deja
pasar por la conciencia pero
asegúrate de hacer esto, que es este punto
que está integrando la
retroalimentación de seguridad en la identificación. El ID es el entorno de
desarrollo integrado. Y con eso, quiero decir, la
codificación que están haciendo, deberían poder obtener
retroalimentación ahí y luego. ¿Bien? Puedes dar tantas
capacitaciones como quieras Los desarrolladores necesitan una forma de obtener comentarios en tiempo
real. ¿Bien? Cuando están
desarrollando el código, cómo hacerles saber que el
código no es seguro, ¿verdad? ¿Qué temas están presentes? Y esta es la
forma más indolora
y sin fricciones de asegurar Créeme, no necesitas hacer pruebas de
seguridad más adelante si el desarrollador
lo sabe de inmediato, si hace un escaneo rápido y ve, mira estos son los inseguros A lo mejor mi código que he escrito
no es seguro, necesito arreglarlo. Esta es la forma más fácil, y si lo haces correctamente, verás un impulso masivo
en tu código de seguridad. ¿Bien? Entonces si tomas un ejemplo, si recuerdas
te mostré este ejemplo desde el principio, como este es un código
que no sanea, se toma
la entrada,
y por supuesto, puede llevar a cosas
como inyección SQL donde la gente realmente puede
acceder a tus bases de datos backend, tus
sistemas operativos, tus archivos, si no lo desinfectas Ahora bien, este es un
ejemplo de un IDE, como código de Visual Studio
donde la gente escribe bien. Y esta es una herramienta, a
qué se llama código
whisperer, que es A. Puedes usar cualquier herramienta. No me gusta mencionar
herramientas específicas, por cierto. Pero si miras
la captura de pantalla, entonces este era el código, el
mismo código que te he mostrado, si lo pongo aquí y ejecuto un escaneo de seguridad,
enseguida, me va a decir, mira que hay
una inyección SeQL, y me dirá la línea Ya ves lo poderoso que
es esto si lo haces correctamente. Entonces puedes decir de inmediato, el desarrollador lo sabrá, mira, estoy introduciendo una
vulnerabilidad de seguridad al código. Necesito arreglar esto antes de
someterlo al repositorio. Y esto conducirá
a un impulso masivo
en la calidad de su código de seguridad. Otra vez, si recuerdas, te
mostré éste, el ataque zip bomb
donde la gente está enviando un archivo que potencialmente puede descomprimirse a GB
de gran cantidad
de datos y estar
abajo del servidor provoca una denegación Entonces, si haces esto, nuevamente, verás de inmediato,
te dará retroalimentación, carga
sin restricciones de archivo
peligroso toque que puedes ver en la parte inferior
y enlace de recursos Entonces esta es una manera
muy, muy poderosa. Te mostré el
ejemplo de código con espolón pero puedes usar
muchas herramientas que se integran en el
propio IDE y dan retroalimentación en tiempo
real al desarrollador. Acerca de qué tipo de código están enviando
y por qué es inseguro Entonces, por favor, miren eso. No cometas el error
que comete el 90% de las personas, que es que dan
capacitación en código de
seguridad a los desarrolladores y luego esperan
que
encuentren todo. No, no va
a funcionar así,
dales herramientas que
les den retroalimentación en tiempo real. Entonces después de eso,
hablamos de pruebas. Ahora, si recuerdas,
hablamos de pruebas, pasa por
el pipeline CSED, va a las pruebas de calidad Aquí es donde puedes
introducir tus diferentes tipos de pruebas de seguridad
para el código. El primero es la prueba de
valores de aplicación
estática o SAS. Esta es una metodología de prueba que analiza tu código fuente. No ejecuta el programa, y generalmente se ejecuta en una etapa temprana durante
la propia fase de codificación. Te lo hará
saber, así que mira el código fuente y
se enterará,
oye, ¿estás introduciendo alguna vulnerabilidad de
seguridad? Puedes integrar las herramientas en
la canalización de CICD y hace un
análisis muy completo de tu base de código Examina el código
porque baja
hasta el nivel de código. El segundo es el DAST, que es una metodología de
prueba de caja negra, es
decir, el código no tiene acceso No es mirar
el código fuente, sino que en realidad se ejecuta. Entonces, durante su ejecución, entonces el programa se está ejecutando. De hecho, simula
ataques externos como la inyección SQL, y se realiza más adelante
en la canalización de CICD Por lo general, cuando tu software está en preprod o en el
ambiente de puesta en escena, ¿verdad? Entonces se parece a las páginas web, y a las APIs, e
intenta explotarlas. Así que los booster ambos
se usan juntos. No hay gente que
intente decir que yo SASPTO es DAS B SAS y DAS ambos se
complementan entre sí DAST identifica las vailabilities desde una perspectiva diferente, y SAS analiza
el Entonces se complementan entre
sí. Idealmente, deberías estar
mirando a ambos. ¿Y cómo se junta? Entonces, si miras a la izquierda, tienes el ID donde
das capacitación a los desarrolladores, y estás poniendo
feedback en el ID. Entonces están escribiendo código seguro. Una vez que envían el código, éste entra en la tubería de CI. Realiza pruebas, informes, construcción y SAST entra en juego Entonces parece
el código fuente. Si el código es inseguro, vuelve al
desarrollador. Por favor, arregla esto. Si pasa, así que si
pasa el ID, pasa el SAS, va a la canalización de CD donde
tienes
el prod de puesta en escena de revisión. Dentro de la puesta en escena,
tienes las das sucediendo. Este es un
ejemplo muy simplista de mirarlo, pero es una herramienta muy,
muy poderosa Entonces, si pones distribuir seguridad
a lo largo de tu ciclo de vida, definitivamente
conducirás a una mayor calidad de código
dentro de tu aplicación. Entonces ese fue el SAST y el polvo. Quiero llegar
al otro ejemplo,
que es, de nuevo, uno de
los ejemplos más cruciales. Creo que esto es lo
que
más piensa la gente cuando habla de seguridad de la cadena de suministro de
software, que es
componentes de terceros o dependencia. Hablamos de las
bibliotecas, ¿verdad? Las bibliotecas porque nadie construye aplicaciones
desde cero. Vas a estar
confiando en bibliotecas,
Bibliotecas como Log FoJ pero
se comprometieron, ¿verdad Así que todas estas bibliotecas pueden
introducir vulnerabilidades, componentes de
terceros, y
son un gran punto ciego. Entonces, ¿qué haces aquí?
Se usa algo llamado análisis de
composición de software. Entonces lo que hace es
mirar tus dependencias. ¿Cuáles son las dependencias? Cuáles son las bibliotecas de software, y en realidad identifica los riesgos de seguridad
que existen. Al igual que SAST se
parece al código fuente. Esta se parece a tus bibliotecas de
terceros, y les dice a los desarrolladores, Oye, tu componente es
vulnerable y en
realidad
puede usarlo en
realidad
puede usarlo manera continua para averiguar si alguna vulnerabilidad es
porque no es estática, ¿verdad? Podría ser posible
que un componente sea seguro y mañana
se vuelva inseguro Entonces el análisis de
composición del software SCS, monitorea completamente y parece lo que está sucediendo Entonces este es un ejemplo de CISA, son un sitio web del gobierno, y tienen una muy
buena publicación, lo
vincularé sobre asegurar la
cadena de suministro de software para desarrolladores Y dan esta
recomendación. Entonces dentro del pipeline, el desarrollador tal vez seleccione un componente para su descarga, ¿verdad? No lo sé, la biblioteca
Log four j. Entonces el componente se pone en un repositorio
seguro intermedio donde se tiene el análisis de
composición del software. Entonces lo escaneará y te hará saber que,
bien, esto es seguro. No hay problemas ahí, y lo
moverá al repositorio
seguro. Y a partir de ahí, el
desarrollador ya puede iniciar sesión, registrarlo y comenzar a
usarlo dentro del código. O a menos que encuentre un
problema, entonces vuelve atrás. Entonces esta es una muy buena
manera de mirarlo, cómo funciona la composición
y el análisis de software. Y si lo miras de
nuevo dentro del pipeline, entonces dentro del ID, tienes
código seguro y feedback, y puedes poner
composición de software y RSS allí también. Entonces, cuando el desarrollador está
registrando una biblioteca, la composición del software Ss
entrará en acción y le saber que esto es inseguro o
dentro del pipeline de CI también Entonces, cuando sucede SAST, SAS puede integrarse con el análisis de
composición de software y hacerle saber, mira, el código es seguro,
pero estás usando
una biblioteca insegura.
Y por último, DAST. Entonces DAS cuando estás haciendo DAS, también
puedes hacer monitoreo de las bibliotecas
que están presentes, y te puede hacer saber en el software en ejecución,
qué problemas hay. Entonces esta era solo
una vista
de alto nivel de la primera parte, que era el
código inseguro y cómo asegurarlo Entonces, a estas alturas, espero que tengas una idea
mucho mejor de los controles que puedes poner en
marcha para asegurar
tu código fuente. Bien, ahora el siguiente,
vamos a ver el endurecimiento del
entorno, cómo endurecemos
los informes de código fuente, los servidores de facturas,
los servidores de paquetes, y
vamos a verlo en un nivel superior y ver
cómo complementa seguridad del código fuente del
software Muchas gracias, y te lo
preguntaré en la siguiente lección.
12. Cómo proteger la cadena de suministro - 3: Hola. Hola a todos.
Bienvenido, bienvenido. Estamos
continuando con nuestra lección ahora. Hemos cubierto la codificación, la codificación
segura blanca y por qué eso es importante y
cómo protegerla. Y hablamos dependencias de
terceros,
también, ¿no? Entonces vamos a
seguir adelante en ese caso, y ahora vamos a estar
hablando de los entornos. Si recuerdas hablamos sobre el entorno desarrollador, el entorno pre prod. Y vamos a hablar los componentes que
hay en esta lección. Entonces, antes que nada, ya sabes, dando
herramientas prácticas, prácticamente, asegurándose de que los desarrolladores sean capaces de hacer lo que quieran. Ese es uno de los retos más
grandes, sabes, en la ciberseguridad, porque si no les das los desarrolladores lo que
necesitan para hacer su trabajo, los desarrolladores son muy conocedores
técnicamente Encontrarán
formas inseguras de hacer su trabajo. Entonces aquí es donde la ciberseguridad siempre
ha sido
un desafío, ¿verdad? Tomemos un ejemplo. Las empresas y los equipos de
ciberseguridad, normalmente
no quieren que el personal esté ejecutando código en sus
estaciones de trabajo o laptops, justo por razones obvias Sin embargo, los desarrolladores necesitan eso. Necesitan la capacidad de instalar herramientas
esenciales y probar
su software de manera efectiva. Ahí es donde
necesitas ser flexible, en el entorno del desarrollador. Y como dije, los desarrolladores
son muy conocedores de la tecnología. Si no
les das lo que quieren, es probable
que
encuentren formas de
sortear los obstáculos que
les impiden trabajar, y eso creará un entorno
inseguro Entonces es por eso que
necesitas pensar en
darle a los desarrolladores la capacidad de
hacer lo que necesitan hacer. Entonces hay muchas maneras de hacerlo. En realidad se puede segmentar
de la red de desarrolladores. Entonces puedes ponerlo en una red
separada, ¿verdad? Conozco gente que puso sus entornos de
desarrollador completamente en la
nube y
lo segregó de la red de producción Lo único que es
combinarlos es un repositorio. Pero son plenos
derechos porque
saben que aunque haya algo
problema pasando ahí, es en la nube,
está completamente segregado de su red de
producción Entonces aquí es donde
hay que pensar. Si un atacante
lo compromete, ¿qué va a pasar? Entonces, porque una vez que un
atacante lo compromete, potencialmente
pueden
inyectar núcleo malicioso, explotar dispositivos comprometidos Entonces hay muchas
formas variadas de hacerlo. Puedes separar, como dije, tu entorno de negocios y tu
entorno de desarrollo, aislar a tus desarrolladores,
del negocio principal. Así que asegúrate de que no tengan acceso a ninguna función crítica del
negocio y piensa en formas de asegurar tu entorno de
desarrollador. Estás poniendo en autenticación
multifactor
dales cosas como VDI, lo que les da un Entonces les da la capacidad de
hacer lo que quieren hacer, pero están restringidos. Se ponen en una caja de arena
particular. Entonces estas son las cosas en las que realmente
necesitas
pensar cuando estás endureciendo
tus entornos, ¿verdad? Cómo aislar a tus desarrolladores de tus
entornos de producción. Y, por supuesto, tienes ambientes
preprod, también. Tienen datos. Asegúrate de que lo estás anonimizando. Lo estás desinfectando en
la mejor medida posible. Contrario a la creencia popular, no
necesitas todos
los datos ahí. Solo necesitas lo suficiente para
simular la producción amplia, pero puede que no necesites todos, por ejemplo, como datos de una
vaca o datos PII, potencialmente
puedes desinfectarlos Entonces piensa en esas cosas. Hay que tener monitoreo
de seguridad. He hablado de anonimización
de datos. Entonces estas son las formas
en las que puedes endurecer tu entorno de desarrollo
y tu
entorno de producción de
P. Y hablamos del endurecimiento. Una de las cosas clave en
las que pensar es la seguridad de tus repositorios de código
fuente, tu servidor de compilación,
tu servidor de paquetes Todas estas cosas
vienen a la mente, ya sea que tenga una canalización CICD o DevOps o simplemente manual Entonces vayamos paso a paso. En primer lugar, es tu repositorio de código. Si recuerdas aquí es donde
pones todo tu código sí. Aquí es donde sus
desarrolladores están poniendo el código y endurecido el
acceso al segador Se puede pensar en poner cosas como
autenticación multifactor ¿Está revisando quién
tiene acceso al repositorio y asegura la
infraestructura subyacente Si es en prem y alguien puede hackear
el propio servidor, entonces realmente no puedes
confiar en el código, que va a estar
encima, ¿verdad Y siempre hacer cumplir ese
principio de privilegio de arrendamiento. No vas a creer
cuántas empresas
conozco comprueban el acceso
de sus aplicaciones, pero las OPI se olvidan
por completo Lo extrañan por completo. Entonces el acceso de usuario a repositorios, piensa en cómo
te autenticaste ¿Existe una buena política de contraseñas? ¿Estás haciendo cumplir cosas como la autenticación
multifactor? ¿Lo estás restringiendo
a direcciones IP? Como hablamos del tema
Cod Cv, ¿verdad? Eso podría haber sido
así si las IPs hubieran sido destruidas porque aunque hubieran comprometido tu repositorio, no
habrían
podido acceder a él Y, por supuesto, una de las cosas
más peligrosas, por favor siga escaneándola. Mantenga siempre sus credenciales y su código fuente separados. ¿Sabes si tus
desarrolladores han codificado alguna credencial
en tu EPO, separando
lógicamente tus
credenciales del Y asegurándose de que
están siendo escaneados. Esta es una de las cosas
más básicas. A la fecha,
te puedo garantizar que tantas empresas tienen credenciales
codificadas dentro sus repositorios y no
están al tanto de ello Entonces, ¿tienes ese plan? Tienes algún
tipo de plan de
respuesta a incidentes si te
enteras, ¿verdad? Estas son todas las cosas en las que
debes
pensar cuando
hablas de tu repositorio de código Si se aseguró el código Depot, ataques como Cod COV
podrían haber sido bloqueados Bien, el siguiente es el pipeline de
construcción, ¿verdad? Hablamos de esto
una vez
que el desarrollador, se
compromete algo con el código, el repositorio Ahí es donde entra su
tubería de construcción. Esto puede ser parte de
la tubería CSCD. Hay que asegurar
esto de manera más crucial, porque este es uno de
los mayores objetivos Ya lo hemos visto
pasar en las victorias solares, ¿
verdad? ¿Qué hace un atacante? Se infiltra en una red de
desarrollo. Escanea para averiguar dónde están
los repositorios de código fuente, dónde están los sistemas construidos y dónde están las vulnerabilidades.
Él lo compromete. Ahora le puede gustar comprometer el código que
se está cometiendo, y puedes comprometer
los binarios, ¿verdad Si desea
asegurar la integridad de su código y los artefactos de
compilación, debe asegurarse de que
su compilación funcione endurecida. Y recuerda esto en todo momento, que los
hilos de construcción son una de las amenazas más peligrosas
que pueden estar ahí, como lo demuestra el entorno de los vientos
solares. Entonces, ¿qué podemos hacer? Entonces, antes que nada, siguiendo
las pautas de endurecimiento. La mayoría de las
herramientas de construcción que están ahí, todas ellas tienen mejores
prácticas de endurecimiento que puedes seguir. Segregue su desarrollo, su red de ingeniería
de la red coopit Ya
hablamos de ello. ¿Estás monitoreando tu entorno de
construcción? Tienes cosas como, una
autenticación multifactor ahí. ¿Por qué? ¿Estás auditando a qué
cuentas tienen acceso? Porque recuerde,
el servidor de compilación, si está implementando automáticamente código en diferentes entornos,
necesitará acceso. ¿Cómo sabes
que esas cuentas no
han sido
comprometidas, verdad? Asegurándose de que está
registrando todos los accesos. Y hablamos de las compilaciones
reproducibles verificadas ,
también, ¿verdad? Entonces construye las cuales puedes construir
en entornos separados, y
siempre serán los mismos. Eso te da la
seguridad de que nadie ha manipulado
un construido como solar Y asegurándose básicamente tus secretos y tus
credenciales estén seguros. Por lo tanto, estas son una lista de verificación completa que puede usar para
comenzar a proteger sus entornos
construidos. Entonces esos son los servidores de compilación. ¿Qué más es el servidor de paquetes? Si recuerdas, entonces pones
cosas en el código fuente, van al servidor de compilación, y a partir de ahí,
van al paquete. Ahora, el servidor de paquetes es donde
se implementa su software, ¿verdad? Usted paquetes de software. Y compromiso de repositorio de
paquetes. Eso puede ser una amenaza significativa en su cadena de suministro de software. Hablamos de esto antes. Si los atacantes pueden
comprometerlo, potencialmente
pueden enviar código
malicioso allí, ¿verdad? Entonces nuevamente, endureciendo MFA, usando firmas criptográficas
. ¿Qué es esto? Usted quiere asegurarse de que la integridad de sus paquetes de
software. Entonces de esta manera, si este paquete
es manipulado o alterado, tu firma criptográfica
entrará en juego Porque el paquete
tendrá una
huella digital única, ¿verdad? Y podemos verificar que
nadie ha manipulado. Así que de nuevo, entonces puedes
asegurarte de que estás usando canales
seguros, asegurándote de que se están utilizando HDDPS, SFTP o incluso VPNs para
asegurarte de que los paquetes
están
encriptados en transet verificando la integridad de
los paquetes encriptados en transet verificando de software antes de su distribución asegurándote de que se están utilizando HDDPS,
SFTP o incluso VPNs para
asegurarte de que los paquetes
están
encriptados en transet verificando la integridad de
los paquetes de software antes de su distribución. Entonces quieres comparar tus
paquetes de
firma criptográfica actual con la firma
original para asegurarte de que nadie
haya manipulado eso, ¿verdad? Y en contra de firmarlo. Estos son algunos de los controles
muy, muy importantes. Y ahora mismo,
quiero llevarte vuelta uno de los
riesgos clave de los que hablamos. Recuerdas esto el ataque
de confusión de dependencia. Este fue un importante, muy, como un batidor de cadena de suministro importante, que es donde el atacante
publica un paquete malicioso un repositorio público de paquetes con el mismo nombre que
un paquete popular Entonces tu desarrollador,
podrían pedir un paquete, y lo que sucede es que
el paquete re primero, lo que hace, comprueba
el informe público. Y ahí el atacante
ha puesto el mismo nombre, pero con un número de
versión mayor. Entonces podrías tener la versión
tres, él pondrá la versión cinco. Y el repositorio de paquetes de la
forma en
que está configurado, primero irá a
Internet para verificar, y descargará el paquete
malicioso Y de esta manera, el
paquete se
copiará en tu
red de desarrolladores y Bingo. El atacante tiene acceso a su entorno de
desarrollo de software y es capaz de comprometerlo. Entonces es solo una forma en que
es un tipo de ataque que explota la forma en que funcionan los entornos de
desarrollo de software y los administradores de paquetes, ya
sabes, cosas
como el
administrador de paquetes de nodos , el índice de paquetes de Python Esta es solo la forma en
que funciona. Entonces, nuevamente, ¿qué puedes hacer asegurando esto? Puedes usar repositorios privados para dependencias críticas, solo
puedes usar repositorios
privados con estrictos controles de acceso para reducir el riesgo de que
consumas accidentalmente Puedes usar el bloqueo de dependencia, asegurándote de que tu dependencia el paquete que está
buscando el desarrollador esté bloqueada a una versión específica
que hayas verificado Evita que esas actualizaciones
automáticas puedan
verse comprometidas en versiones más nuevas. En este diagrama,
puedes ver que el atacante ha comprometido un repositorio de
paquetes públicos, ¿verdad Y el desarrollador
pidió un paquete. El paquete no irá a
Internet para comprobarlo. ¿Por qué? Porque has
cerrado la dependencia. Has dicho que esta es
la única versión que quiero, que ya has
verificado, que está en prem Por lo que no irá a
Internet y podrás eludir por completo este ataque. El atacante no podrá comprometer tu entorno. Entonces estas son las cosas que
quiero que tengas en cuenta, que es proteger contra ataques de confusión de
dependencia, ¿verdad? Estas son las cosas que
necesita pensar verificación del
nombre del paquete que los nombres de todos los paquetes que se utilizan en su proyecto son
conocidos y confiables. Y puedes hacerlo
verificando el origen y mantenedor de cada paquete antes de agregarlo a
tus dependencias Firma de paquete de
ya se habló. Lo mismo que tienes una firma
digital, ¿verdad? Firmar el paquete y usar
repositorios de paquetes privados, así que considere usar repositorios de
paquetes privados donde
aloje sus dependencias internas Esto puede ayudar a
reducir al atacante, como mostré en el diagrama
anterior. Incluso si introduce
un paquete malicioso, que tiene el mismo nombre que
tu dependencia interna, tu gestor de paquetes no
irá ahí porque va a permanecer en prem y solo
usará el interno Y claro, monitoreando y escaneando tus
paquetes, ¿verdad? Se quiere asegurarse de
que no se
hayan introducido
vulnerabilidades mientras tanto. Por lo que esto puede ayudar a capturar
cualquier
paquete malicioso
y monitorear las descargas de paquetes . Por lo que al monitorear las
descargas de tu paquete, puedes ayudar a detectar
cualquier actividad maliciosa. Entonces estas son todas
las cosas que puedes hacer para asegurarte seguro contra ataques de confusión de
dependencia. Así que ya hemos cubierto
los entornos. Ahora quiero hablar sobre un tema
muy importante que es crucial cuando se trata de seguridad de la cadena de suministro de
software, y esta es la compilación de software
de material, SBOM Gracias. Y no voy a cubrir
esto porque creo que ya tienes suficientes cosas para
entender en esta lección. Te veré en la siguiente lección, iniciaremos este tema. Muchas gracias, y nos
vemos en la siguiente lección.
13. SBOM: Hola a todos.
Bienvenida. Bienvenido a esta lección, que
cubre un tema muy,
muy importante en la seguridad de la cadena de suministro de
software, que es un software construye
de material, SBOYM Entonces, ¿qué es un SBM?
Es muy sencillo. Básicamente es un inventario
anidado. Es una lista de ingredientes. De todos los componentes de software que están presentes
dentro de su software. Y si piensas en la cadena de suministro de
software, bien, cada framework de herramientas o
compilación utilizada para escribir, construir y ejecutar aplicaciones, y aquí es donde entran todas las
vulnerabilidades, ¿verdad? Y estás constantemente
reutilizando código, paquetes de
software y proveedores
externos también venden paquetes comerciales Entonces la complejidad de construir todas estas
aplicaciones de software, hace que sea muy, muy crucial
tener un inventario de todos los componentes que se utilizan para crear dicha
aplicación, un catálogo, ¿verdad? Y este catálogo ayuda a las organizaciones a identificar y
detectar
rápidamente si tienen alguna vulnerabilidad de seguridad
dentro del entorno. Entonces aquí es donde entra
el SBM. Se ha vuelto muy parecido un estándar en la seguridad de la cadena
de suministro de software. Y aquí es donde
realmente puedes preguntar a los
vendedores y obtener esto. Y vamos a
investigar esto con más detalle. Así que en realidad puedes
hacerlo tú mismo. Incluso puedes hacerlo
con hoja de Excel. Yo no lo recomendaría en absoluto, o puedes
generarlo automáticamente. Hay muchos, muchos softwares que escanean su entorno, y luego realmente generan o construyen software de materiales Eso es lo que recomiendo usar
una máquina generada. Y es muy, muy
beneficioso, ¿por qué? Porque te ayuda a identificar componentes
vulnerables y te
da un conocimiento completo
de lo que tienes, ¿verdad? ¿Y si hay un incidente de una biblioteca en particular que
está siendo comprometida? ¿Cómo sabrías si tus aplicaciones críticas
tienen esto o no? De hecho, puedes consultar
rápidamente tu SBM, si está ahí en
formato máquina para saber si se esta versión en particular de está utilizando
esta versión en particular de
esta biblioteca en particular, ¿verdad Y te ayuda a seleccionar
proveedores también que están escribiendo, como si tu vendedor es
transparente y dice,
Oye, aquí está mi SBM
con la aplicación Sabes que este es un vendedor
maduro, ¿verdad? Tienen todas estas
cosas necesarias. E incluso después de que creo
que fueron las victorias solares, los proveedores de la
cadena de suministro de software y la seguridad de la
orden ejecutiva que se produjo, también
comenzaron a exigir
que se necesita tener un SPOM Entonces como dije, puedes
hacerlo de forma manual, usa una hoja de Excel. Absolutamente no lo
recomendaría porque
puedes tener de cientos a
miles de dependencias. Por lo general, puedes hacerlo usando herramientas generadas por
máquina, derecho, que son completamente
hazlo automáticamente por ti. Entonces, como dije, ¿qué hace? Es como un inventario completamente
exhaustivo, ¿verdad? Detalla cada pieza de código
abierto de terceros, bibliotecas, paquetes de
código que
se utilizan en el desarrollo de una aplicación de
software, y te da una buena idea de la
composición del software, ¿verdad? De esta manera sabes qué
hay, qué no hay, qué versión estás usando, ¿qué bibliotecas y
paquetes de código están usando? Cómo son
los componentes de terceros, ¿ cuál es el estado PAT? ¿Cuáles son las dependencias
entre ellos? Y ahora puedes entender, si quisiera saber cuál es el
estado de PAT porque no
sé si el software en particular es vulnerable o no a
un ataque en particular, la SBOM puede
ayudarte de inmediato a identificarlo Y esto es como una
máquina generada . Así es como se ve. O sea, no quiero
que lo leas, pero solo muestra que puedes ver que te muestra
cuál es el paquete. ¿Correcto? ¿Cuál es el estado?
¿Cuál es la versión? ¿Cuál es el código hash?
¿Quién es el proveedor? Entonces entran en
juego todas estas cosas. ¿Y cómo ayuda? Entonces ya
hablé de esto, pero, ya sabes, antes que
nada, tienes transparencia. Entonces te da una
lista completa de lo que tienes, ¿verdad? Este nivel de transparencia
permite a las empresas conocer exactamente qué hay
en el software y hacerlo más
fácil de administrar y asegurar. Administración de vulnerabilidades con SBM, puede identificar rápidamente si hay
algún
componente de software que sea vulnerable a problemas
de seguridad Para que puedas
identificar de manera proactiva los problemas. Cumplimiento, muchas industrias tienen requisitos
regulatorios
que exigen estándares
de seguridad para el software. Entonces, si no lo haces aunque no tengas el
software en la casa, tal vez estés usando un software basado en
proveedores. Se puede utilizar una lista de materiales especiales. Puedes pedirle al vendedor
el SBM, ¿verdad? Y por supuesto, la seguridad de
la cadena de suministro. El objetivo de esto es
mejorar la seguridad de su
cadena de suministro, y también ayuda a una respuesta a
incidentes. Digamos que, en caso
de una respuesta a incidentes, SBM le permite respuesta a
incidentes más
rápida y eficiente Puede determinar rápidamente
qué componentes podrían verse
afectados por un ataque. Y nuevamente, seguimiento de dependencias. Entonces como dije, se vuelve tan complicado
rastrear lo que tienes y
lo que no tienes. Por lo tanto, un SVM te ayuda a rastrear
estas dependencias a lo largo del tiempo. Y hoy en día en la era
de GNAI y todo, realidad
puedes poner una
IA encima de estos archivos y consultarla y obtener respuestas de la vida completamente humana, ¿verdad Entonces todas estas cosas en las que
puedes pensar. Entonces, si lo miro
desde esta perspectiva. Entonces suponiendo que tienes
un equipo de ciberseguridad,
correcto, y tu empresa está comprando un producto
a un proveedor Y ahora el equipo de ciberseguridad quieren saber qué
tipo de software hay ¿Es de código abierto? ¿Cómo
se construye, verdad? Entonces le preguntas al vendedor, me
puede dar por favor un SBM Entonces esto es lo que el
vendedor responde bien. Te dan una SBOM y la persona ahora es capaz de
leerla y obtener esa seguridad Bien, ¿qué hay?
¿Qué no hay ahí? Ahora, ningún software es inmune a
las vulnerabilidades de seguridad, ¿verdad? Cada No hay ningún software que sea completamente seguro al 100%. Así que en realidad incluso puedes
hacer eso con una SBOM. Para que pueda preguntarle al proveedor, ¿hay alguna vulnerabilidad
en sus redes de laboratorio de software? Te pueden dar OSB
más algo llamado intercambio vulnerabilidad
explotabilidad. Ahora, ¿qué es eso? Este es un framework
que está diseñado para comunicar las
vulnerabilidades de seguridad en el software, particularmente si el software
es vulnerable o no. Por lo tanto, las declaraciones VX,
proporcionan a los proveedores una
forma de comunicarse Ya sea que haya una vulnerabilidad o no, se les puede
decir exactamente. Entonces, si soy vendedor y
un cliente me pregunta, puedo darles
el SBM más un VX Y digo que
esta vulnerabilidad no
es una preocupación
para nuestro producto, y puedes detallar
las condiciones
bajo las cuales
podría ser un problema, pero la has
mitigado, ¿verdad Entonces es parte de la SBOM y
te da transparencia Entonces este es, nuevamente,
un estándar que se está volviendo cada vez más popular en la cadena de suministro de software. ¿Por qué porque no tienes acceso a externalizar el código
fuente, verdad Pero si estás comprando
una aplicación, en realidad
puedes usar el SPM Puedes usar el VX para
obtener esa garantía. Y en la siguiente lección,
lo que vamos a hacer
es hacer un estudio de caso real,
como, ¿cómo pasaría eso si un cliente estuviera comprando un
software y qué podemos hacer? Entonces creo que esto cubre prácticamente todas las
cosas de las que hablamos, ¿verdad? Así que lo hemos mirado desde
el entorno de desarrollador, codificación
segura, endurecimiento, escaneo de
componentes,
pruebas, endurecimiento del entorno y ahora mirándolo desde
la perspectiva SBM Entonces espero que esto te haya sido útil
para entender lo
vasto que es este mundo, ¿verdad? Ahora, tienes una
buena idea de lo que la seguridad de la
cadena de suministro de software y los controles en cada etapa y los conceptos erróneos que la
gente tiene como este es un producto que compras
o esta es una
certificación que obtienes o esta es una
certificación Entonces ahora que estás
en buen estado, podemos ahora
podrías estar pensando, Bien, hay
tantos controles. ¿Cómo puedo implementar realmente? ¿Por dónde empiezo
empiezo con el SBM? ¿Empiezo con código seguro? ¿Empiezo con dependencias?
¿Qué tengo que hacer? Entonces esto es de lo que vamos a
hablar en la siguiente
lección donde
vamos a hablar sobre la construcción de
una cadena de suministro de software, seguridad y programa de riesgos. Como si empiezas a hacer
esto dentro de tu empresa, dónde empezar y dónde van a entrar
todos estos diferentes componentes. ¿Bien? Entonces espero que esto te haya sido
útil.
Te veré en la siguiente lección. Gracias.
14. Conclusión: Hola, hola a
todos. Bienvenida. Bienvenidos a la lección final. Y esto solo está
terminando. Gracias. Gracias por escucharme, hablar por Dios sabe cuanto tiempo. Pero espero que haya entendido bien seguridad de la
cadena
de suministro de software. Espero que ahora tengas una visión
holística, y no solo estés
pensando en comprar un producto o simplemente encender
MFA o algo así Espero haber aumentado
sus conocimientos sobre nuevos tipos de ataques. Así que recuerda, es
un viaje continuo. Siga las mejores prácticas
y tendencias de la industria que están
ahí y comience. Yo no puedo, por favor,
no seas de esas personas que acaban de
tomar esta lección, y luego te
olvidas de ello la semana siguiente. Bien, empieza, toma algunas de las
lecciones de las que te he
hablado y empieza a
implementarlo dentro de tu empresa. Eche un vistazo a los repositorios construidos,
los repositorios de paquetes y comience a implementarlos de manera incremental
. Pero eso es más o menos que
hemos terminado el curso. Espero que hayas disfrutado
escuchándome Babilonia por tantas horas. Muchas gracias por
aguantarme. Recuerda que te di un
proyecto al inicio. Puedes tomar esto y separarlo tu propia cadena de suministro de software contra el riesgo del que
hablamos y compartirlo. Y eche un vistazo como hacer una simple evaluación de dónde se encuentra,
su cadena de suministro, cuáles son los riesgos y
cómo puede mitigarlos, documentarlo para que pueda
hacerse una mejor idea. Porque si no
aplicas este conocimiento, puedo garantizar que te
olvidarás de ello. Habrás desperdiciado tu
tiempo y dinero si no aplicas los conocimientos de los que te he hablado. Así
que eso es más o menos. Por favor, no
dude en comunicarse conmigo. Estoy ahí en Substack, LinkedIn y también tengo un pequeño canal de
YouTube Vinculo todo
dentro de los comentarios. Lo siento, dentro de la lección,
puedes hacer clic en ella, y contactarme si pensabas que esta
era una buena lección, por favor deja una si
pensabas que este era el peor curso
que hayas tomado, avísame, por favor, también. No te preocupes en absoluto.
Estoy feliz de recibir comentarios. Así
que muchas gracias. Esto concluye este curso. Espero que la hayas pasado bien, y te
veré en el próximo
curso que imparto. Muchas gracias y adiós.
Taimur Ijlal, Cloud Security expert, teacher, blogger
