Un área importante de preocupación para los equipos de seguridad de TI es cómo abordar los desafíos que plantea el uso cada vez mayor de plataformas y servicios de terceros. La necesidad de seguridad que abarque a terceros se aplica a través de cadenas de suministro físicas, cadenas de suministro de software y contratos de subcontratación.
En su Perspectivas del CEO del Reino Unido para 2021 informe, KPMG descubrió que el 81 % de los líderes consideraban que proteger el ecosistema de sus socios y la cadena de suministro era tan importante como construir las defensas cibernéticas de su propia organización.
En enero de 2022, la Casa Blanca convocó a las partes interesadas del gobierno y del sector privado para discutir iniciativas para mejorar la seguridad del software de código abierto y las formas en que la nueva colaboración puede impulsar la mejora.
El presidente de los Estados Unidos, Joe Biden, ha hecho de la seguridad del software una prioridad nacional. Su orden ejecutiva sobre seguridad cibernética requiere que solo las empresas que utilicen prácticas de ciclo de vida de desarrollo de software seguro y cumplan con las pautas de seguridad federal específicas podrán vender al gobierno federal.
La orden también insta a la industria a impulsar el uso de listas de materiales de software (SBOM), cuyo objetivo es facilitar que las personas y las organizaciones que compran software entiendan qué componentes se usaron para construir los productos que usan.
Al hablar sobre los riesgos inherentes a una cadena de suministro de software, Mike Gillespie, director gerente y cofundador de la consultora de seguridad independiente Advent IM, dice: “Sabemos que las infracciones de terceros han ocupado los titulares en los últimos años. Esto no solo no muestra signos de cambio, sino que, a medida que continuamos trabajando en estilos remotos e híbridos, los resultados de una implementación de tecnología deficiente y una gestión de riesgos de seguridad deficiente potencialmente ponen a más organizaciones en riesgo entre sí. Y sabemos muy bien cuán rápido se explotan los vínculos entre los socios de la cadena de suministro en estos días”.
Los últimos datos disponibles de la Oficina del Comisionado de Información del Reino Unido (ICO), que analizan el tercer trimestre de 2021, encontraron que el 51% de las organizaciones han sido violadas debido a un tercero en los últimos 12 meses. La ICO descubrió que las tres cuartas partes de estas infracciones se debieron a que terceros tenían demasiado acceso privilegiado.
Gillespie recomienda que las organizaciones trabajen para estar más unidas con un mejor flujo de información para la gestión de riesgos. “Muy pocas evaluaciones de riesgos comienzan con una evaluación de amenazas detallada y bien informada, lo que significa que el tratamiento de riesgos a menudo es defectuoso”, dice.
Tubería de seguridad de código abierto
El desarrollo de software moderno se basa en gran medida en el uso de componentes de código abierto. Estos componentes a menudo atraen a otras bibliotecas de código abierto, construyendo, como dice el refrán, sobre los hombros de gigantes.
En mayo de 2021, Biden emitió una orden ejecutiva para mejorar la seguridad del software mediante el establecimiento de estándares de seguridad básicos para el desarrollo de software vendido al gobierno, lo que requiere que los desarrolladores de software mantengan una mayor visibilidad de su software y pongan a disposición del público los datos de seguridad.
En el complejo mundo de una cadena de suministro de software, el desafío para un director de seguridad de la información (CISO) no es solo identificar todos los componentes potenciales de código abierto que se han utilizado en un sistema empresarial, sino también cómo auditar a los mantenedores de estos proyectos. , para asegurarse de que han establecido prácticas de codificación seguras y corregirán las vulnerabilidades de manera oportuna.
Dado que el código fuente abierto disponible gratuitamente puede extraerse de un repositorio como GitHub y luego incorporarse al software empresarial, no hay garantías de que el proveedor del software empresarial pueda presionar al mantenedor del código para solucionar cualquier problema que surja. .
“La mayor parte del código abierto es abandonware inútil: puedes encontrar decenas de millones de proyectos de este tipo solo en GitHub. Para ser útil, un proyecto de código abierto necesita más que una licencia: necesita al menos una gobernanza adecuada”
Peter Zaitsev, Percona
El software de código abierto sin procesar tiende a venir “tal cual”, sin garantía y sin obligaciones de ninguna de las partes, dice Peter Zaitsev, director ejecutivo de Percona. “Las cosas suceden en base a relaciones de buena voluntad y negociaciones”, agrega. “Si desea alguna garantía (ayuda y soporte, corrección de errores, mantenimiento de versiones antiguas, etc.), todo esto viene con acuerdos comerciales con empresas o desarrolladores individuales”.
Mientras que la comunidad de código abierto habla sobre la licencia del proyecto, y cualquier código con licencia aprobada por una iniciativa de código abierto califica como código abierto, Zaitsev dice: “La mayoría de los códigos abiertos son abandonware inútil: puede encontrar decenas de millones de proyectos de este tipo en GitHub solo. Para ser útil, un proyecto de código abierto necesita más que una licencia: necesita al menos una gobernanza adecuada”.
Esto, dice, necesita, como mínimo, estipular cómo se toman las decisiones sobre lo que se incluye en el proyecto y la forma en que los desarrolladores benévolos, actuando en interés de los usuarios, pueden contribuir al proyecto.
“Esta es la razón por la que, al elegir un software de código abierto del que depender, es una buena idea elegir un software con un historial establecido, respaldado por una organización no comercial de confianza (por ejemplo, CNCF) o un proveedor comercial que esté directamente interesado. en el mercado”, añade Zaitsev.
Muchas empresas aportan código fuente abierto que han desarrollado internamente para resolver un problema comercial, pero no tienen ningún interés comercial en ese código. Un ejemplo de un proyecto de este tipo es RocksDB, un motor de almacenamiento mantenido por Facebook, que administra la forma en que se almacenan los datos y los metadatos.
Apache Kafka Streams es uno de los componentes de código abierto que utiliza RocksDB. En una publicación de blog que coescribió, Bruno Cadonna, desarrollador de software en Confluent y responsable de Apache en Kafka, describe RocksDB como un “almacén de valor clave altamente adaptable, integrable y persistente”, y agrega que “muchas empresas usan RocksDB en su infraestructura para obtener un alto rendimiento para servir datos”.
En el blog, Cadonna y la coautora Dhruba Borthakur, directora de tecnología de Rockset, describen cómo optimizar RocksDB para Kafka Streams, para implementar aplicaciones y microservicios altamente escalables y elásticos que procesan y analizan datos almacenados en Kafka.
La publicación del blog ilustra cómo los colaboradores externos en la comunidad de código abierto se basan en componentes de código abierto para desarrollar nuevos productos y servicios.
La tecnología RocksDB está incluida en Percona Distribution para MySQL y MongoRocks es una versión de RocksDB para MongoDB. Si bien Confluent, Rockset y Percona tienen ofertas comerciales construidas sobre RocksDB, existe la pregunta de cómo las organizaciones hacen que las cosas cambien de manera oportuna.
“Siempre encontramos al equipo de RocksDB de Facebook bastante práctico y razonable, aunque como con cualquier fuente abierta enfocada internamente, ellos están naturalmente enfocados en sus propias necesidades”, dice Zaitsev. “No están construyendo un negocio alrededor de RocksDB”.
El problema de la cadena de suministro de software
Más allá de la necesidad de contratos comerciales con acuerdos de nivel de servicio para respaldar las correcciones de errores y fallas de seguridad en los componentes de código abierto, los CISO deben comprender la cadena de suministro de software completa de extremo a extremo sobre la cual se construye la arquitectura empresarial de la organización.
Petra Wenham, voluntaria de BCS con una larga experiencia en seguridad y garantía de la información, advierte que el uso de plataformas y servicios de terceros, y los cambios en la forma en que se aprovisiona la infraestructura de TI de una empresa, brinda a los actores maliciosos una superficie de ataque mucho mayor para jugar con. Una vez obtenido el acceso, el atacante tiene una gama más amplia de oportunidades para moverse a través de la infraestructura de TI de la empresa objetivo.
“Asumiendo que el equipo de seguridad tiene una sólida comprensión del negocio de la organización y sus procesos internos y externos, un buen punto de partida sería mapear todos los procesos y subprocesos: TI, papel y otros”, dice.
“El objetivo de este mapeo es identificar los diversos límites entre las aplicaciones y los servicios, incluso donde los propios terceros utilizan servicios de terceros. Al hacerlo, debería poder identificar qué tipo de control debería tener sobre los servicios individuales y el límite de interconexión entre los servicios”.
Elizabeth Huthman, directora cibernética de KPMG Reino Unido, señala que algunas organizaciones son más inteligentes en el uso de la tecnología para mejorar los programas de gestión de riesgos de terceros. Esto, dice, significa ir más allá de las evaluaciones puntuales, que pueden estar desactualizadas en una semana, al uso de monitoreo de control continuo, que les permite tener una visión siempre viva del entorno de riesgo.
Huthman dice que algunos clientes de KPMG están incorporando herramientas de gobierno, riesgo y cumplimiento (GRC) para informes enriquecidos, en lugar de depender de hojas de cálculo para ingresar métricas de seguridad manualmente. Otros también están tratando de crear una mejor imagen de su entorno de TI para saber si otro ataque como Log4j volverá a ocurrir y cuáles de los proveedores de la organización son más susceptibles.
Pero, como señala Huthman, “es un gran desafío” comprender el riesgo más abajo en la cadena de suministro. “Mucho [of organisations] están excavando en la capa de cuartas partes debido a las dependencias entre terceras y cuartas partes. Creo que como organización, tenemos que tomar una posición. No vas a llegar hasta el final con todos los proveedores. Tienes que extrapolar”.
El punto que plantea Huthman es relevante para la forma en que los CISO gestionan el riesgo de seguridad inherente a las arquitecturas empresariales complejas construidas sobre capas de componentes de software altamente interdependientes, algunos de los cuales pueden provenir de organizaciones, o se basan en componentes de código abierto, donde el nivel de seguridad puede ser a un nivel inferior al que la empresa normalmente considera aceptable.
La razón por la que una empresa más grande puede optar por trabajar con organizaciones más pequeñas y ágiles, dice Martin Tyley, jefe de cibernética de KPMG Reino Unido, es que les permite innovar más rápido. “Sus habilidades están en la agilidad y son rápidos para innovar, pero estas características conllevan más riesgo”, dice. “A veces quieres que alguien más haga cosas increíbles y traiga grandes cosas”.
Pero esto tendrá un riesgo. Los CISO deberán equilibrar el riesgo para la organización con el riesgo asociado con la limitación de la capacidad de innovar aprovechando lo que los proveedores externos tienen para ofrecer.
