La semana pasada, los legisladores federales comenzaron el proceso de proteger mejor el software de código abierto utilizado por las agencias gubernamentales con un nuevo proyecto de ley llamado Ley de Protección de Software de Código Abierto de 2022.
Los senadores Gary Peters (D-Michigan) y el senador Rob Portman (R-Ohio) introdujeron una legislación destinada a abordar los riesgos del software de código abierto del gobierno. El proyecto de ley propuesto S. 4913 ahora está esperando la acción del Comité de Asuntos Gubernamentales y Seguridad Nacional.
La legislación se produjo después de que Peters y Portman celebraran una audiencia el 2 de febrero para investigar Eventos log4j El software fue descubierto en diciembre de 2021. Dirige a la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) para ayudar a garantizar el uso seguro y protegido del software de código abierto por parte del gobierno federal, la infraestructura crítica y otras agencias.
Peters, presidente del Comité de Asuntos Gubernamentales y Seguridad Nacional, convocó a expertos de la industria de la seguridad cibernética y la comunidad de investigación para una audiencia en febrero para examinar una vulnerabilidad descubierta recientemente en Log4j. Los expertos en ciberseguridad han calificado la violación como una de las más graves y generalizadas de la historia.
Tabla de Contenidos
solución bipartidista
En esa audiencia de febrero, Peters destacó un paquete legislativo bipartidista histórico que mejoraría la capacidad del país para combatir las persistentes amenazas de seguridad cibernética a la infraestructura crítica y al gobierno federal. Destacó posibles ataques cibernéticos por parte del gobierno ruso en represalia por el apoyo de Estados Unidos a Ucrania.
Log4j significa Java Logging Utility y es parte del proyecto de código abierto Apache Logging Service dentro de Apache Software Foundation. El software incluye varias variantes del marco de registro Log4j para diferentes implementaciones programáticas y casos de uso.
La preocupación de seguridad se refiere a las vulnerabilidades de ejecución remota de código que permiten a los atacantes colocar malware o ransomware en los sistemas objetivo. Esto puede llevar al compromiso total de la red y al robo de información confidencial, así como a la posibilidad de infracciones.
La falla «ha dejado todo, desde nuestra infraestructura crítica, como nuestros bancos y redes eléctricas, hasta las agencias gubernamentales vulnerables a las infracciones cibernéticas. Las fallas en los códigos pueden tener un impacto desastroso en las vidas y los medios de subsistencia de los estadounidenses», dijo Peters en una audiencia en febrero. discurso de apertura.
cual es la sugerencia
El proyecto de ley propuesto establece las responsabilidades del director de la Agencia de Seguridad de Infraestructura y Ciberseguridad con respecto a la seguridad del software de fuente abierta y otros aspectos. Justifica la necesidad de emplear dos factores clave:
- Un ecosistema de software de código abierto saludable, vibrante y resistente es fundamental para garantizar la seguridad nacional y la vitalidad económica de los Estados Unidos.
- El software de código abierto es parte de la base de la infraestructura digital que promueve una Internet libre y abierta.
Bajo el proyecto de ley propuesto, las fortalezas únicas del software de código abierto y la inversión histórica inconsistente en la seguridad del software de código abierto plantean desafíos particulares para proteger el software de código abierto. Por lo tanto, el gobierno federal debe desempeñar un papel de apoyo para garantizar la seguridad a largo plazo del software de fuente abierta.
El propósito de la legislación propuesta es modificar ciertas definiciones de software de código abierto y otras disposiciones de la Ley de Seguridad Nacional de 2002 con respecto a la seguridad cibernética y el uso gubernamental.
Un elemento clave del proyecto de ley es aclarar el significado y el establecimiento de una Lista de materiales de software (SBOM). El segundo factor se centra en las responsabilidades de los directores de las agencias de ciberseguridad y seguridad de la infraestructura y los pasos específicos para garantizar y regular los esfuerzos de ciberseguridad.
Vista interna
La gestión de software de código abierto es fundamentalmente diferente a la gestión de software comercial.No importa si el software está listo para usar o creado bajo contrato, dijo Tim Mackey, estratega jefe de seguridad de la compañía. Sinopsis Centro de Investigación en Seguridad Cibernética.
«Proteger adecuadamente el software de código abierto requiere comprender esta y otras realidades de cómo el código abierto ingresa a organizaciones como el gobierno de los EE. UU.», dijo a LinuxInsider.
La Ley de Software de Código Abierto de 2022 recomienda muchas actividades que tradicionalmente han sido responsabilidad de la Oficina del Programa de Código Abierto (OSPO). Por ejemplo, OSPO es responsable de determinar los riesgos de código abierto aceptables de una aplicación y el entorno en el que se implementa, señaló.
anunciar
«Si bien S.4913 tiene muchas cosas que me gustan, el hecho de que no se mencione cómo se prueba el software de código abierto es preocupante. Hay muchas prácticas de desarrollo de software que pueden crear debilidades en el software, algunas de las cuales dependen de los lenguajes de programación. , dijo McKee al criticar la legislación propuesta.
Las capacidades de las diversas herramientas de prueba (comerciales y de código abierto) también varían ampliamente. Propone que la calidad de las pruebas de software y los objetivos de seguridad utilizados durante las pruebas son tan importantes en el software de código abierto como en el software comercial.
Dan Lorenc, cofundador y director ejecutivo protector de cadena, para descubrir averías en otras zonas no incluidas en la factura de la red. Por ejemplo, el gobierno federal no comprende la prevalencia del software de código abierto en la actualidad. Esta realidad presenta un desafío para vigilar algo de esta escala, casi equivalente a vigilar la libertad de expresión.
“La realidad es que con la creciente necesidad de protocolos de seguridad más sólidos, los mantenedores de software de código abierto ya enfrentan una enorme carga para mantenerse al día con el ritmo de la innovación y la productividad, que es una prioridad para todo el ecosistema”, dijo Lorenz a Linux Insider.
Agregó que necesitaban recursos y apoyo del gobierno en lugar de forzar el cambio a través de la regulación en papel.
expresar más preocupaciones
Un punto brillante en el proyecto de ley actual es que CISA se involucrará más con el software de código abierto y contratará a mantenedores talentosos. Según Lorenc, los nuevos empleados deben familiarizarse con el espacio y, en última instancia, contribuir a la comunidad con las soluciones de seguridad de código abierto que construyen en el camino.
El código abierto está aquí para quedarse. En lugar de discutir sobre sus méritos, debemos mirar hacia adelante y reconocer las ventajas únicas que ofrece el código abierto, y usar esas ventajas para mejorar la seguridad de la infraestructura crítica de nuestra nación”, sugirió.
Otra área que no está bien considerada por la legislación, señaló Lorenc, es el despliegue de SBOM. El despliegue es bajo y son los primeros días en el espacio.
«Este es solo uno de los muchos problemas que enfrentará el gobierno cuando se trata de finalizar la lista de software crítico. Esto se ha intentado varias veces en el pasado en la industria, pero sigue siendo un desafío», dijeron la Universidad de Harvard y Fundación Linux Como un intento reciente”, ofreció.
anunciar
Señaló que el gobierno debería priorizar esta área trabajando en estrecha colaboración con la industria. Cualquier lista tiene implicaciones comerciales más amplias, y la industria tiene más datos disponibles en la actualidad.
«Es posible hacer un inventario de software crítico este año, pero uno preciso será un desafío. Las herramientas SBOM aún son muy tempranas, y la mayoría de las herramientas en uso hoy en día se enfocan en enfoques basados en SCA que solo pueden adivinar el software». contenido interno», explicó.
Se necesitan datos SBOM de mayor calidad para comprender verdaderamente el software utilizado por la industria y el gobierno federal. De cualquier manera, el gobierno debe ser muy transparente sobre la metodología utilizada para determinar esta lista, agregó Lorenc. También lo son las desventajas y desventajas de estos métodos para permitir que la industria en general interprete correctamente la lista.
