 Hi, I'm Rani Haibi, CTO of Networking, Edge and Access at the Linus Foundation. Today I'm going to talk to you about how open-source software projects help make modern 5G networks more secure. First, let's talk about what's driving open-source software for 5G networks. With increased competition, operators seek operational agility to allow them to address market needs and cost reduction to allow them to stay competitive in the market. With increased network complexity, there's a need for software-controlled automation. And they need to build and secure scalable networks across multiple edge locations. If we look at the traditional way for telco innovation, we know that there has been strong reliance on standardization, which means that traditionally, first standards were developed by a multi-company workgroup that designed the specification to address new use cases. Then there was vendor-specific implementation, meaning each R&D team of each vendor interpreted the specification and created an implementation based on their understanding. Tender was a need for what is called interoperability testing, where companies get together and try to make their products talk to each other, often finding out that there could be more than one interpretation of the specification, which called for the next phase, where R&D teams go back to the drawing board, refine their implementation based on their understanding, and then prepare for the next phase of testing. And at some point, go back to the testing phase, repeat that until the desired result is achieved. Now, with open source software, there's a way to accelerate the process. What we're seeing is that open source implementations happen in parallel to the standard specification. This is a joint effort, and it continues to evolve as the spec evolves. But at the same time, it creates this feedback loop that you see in the middle of this diagram. This feedback loop between the standardization process and the open source development allows the open source community to identify ambiguity and errors in the specification to propose practical solutions for these issues. And after that, updating the specifications, the open source implementation can also be updated and continue this continuous feedback loop. This way, based on the learning of the implementation experience, the standard specification process can incorporate the changes before it's finalized, therefore completing the process faster and providing a better outcome. We're seeing that approach of using open source software proliferate across network domains. This is just a partial list of projects that are used in networks, open source projects that are using networks. You can see it starts with the core network and the cloud domain where there are various different projects at various layers of the stack. It continues to the edge network, either the service provider edge or the extreme user edge where there are various open source projects addressing the needs and the infrastructure there. And it goes all the way even to the enterprise network where we see open source usage for enterprise use cases. Now that we understand why open source makes sense for networks, let's talk about the security threats that exist. So as we know, all software is under attack via vulnerabilities or supply chain weaknesses. Here you can see a very small list of recent, very famous incidents and vulnerabilities that were discovered and got high visibility, starting with attacks on popular infrastructure like GitHub, vulnerabilities in popular libraries like log4j, attacks on the supply change that compromised popular software like SolarWinds that created threats to crucial infrastructure and recent studies have shown that their amount of attacks continues to be on the rise. A research and survey conducted by the Livings Foundation discovered that out of the surveyed organizations 98% said that they are using open source software and 95% of the organizations stated that they are concerned about the security of open source software. However, less than half of the surveyed companies said that they're using software build of materials, S-bombs, or a methodical way to trace and track the origins of the open source software that they're using. Another research conducted by the Livings Foundation was based on more than 600,000 data points coming from software composition analysis tools and security companies. And some of the findings in this survey were very interesting and they indicated that the entire software development life cycle is important, not just the vulnerability management. Also, it identified that packaging and integration are an important part of securing the entire software supply chain. And it identified that several projects within domains, a few projects within domains, actually determine the criticality of security because they are very widely used by other projects. When looking at 5G networks, we see a large set of security risks. It starts with the increased attack surface. When we're talking in 5G about millions and even billions of devices connected to the network, 5G makes it even more dangerous than before. There is a risk for more sophisticated botnets and there is a higher risk for privacy and data extraction. More IoT devices mean more problems. Again, the 5G networks enables more IoT devices to connect to the network. But we all know that these devices are inherently insecure and most time security is not built in by design. So each insecure IoT devices in the organization network represents another potential security hole that can be exploited by an attacker. Another issue is a decreased network visibility. With 5G networks expand and become more usable by mobile users and devices, which means that there's more traffic network traffic to manage and analyze. But companies may not be able to gain the network visibility that they had before that is required to identify anomalies or identify attacks on time. And then there are issues related to the supply chain and the software. So compared to traditional mobile networks, 5G is more reliant on software, which elevates the risk of exploitations of the network infrastructure. Currently, there is also a limited set of vendors in the supply chain, which means that it's even more susceptible to attacks. And that increased the potential for insecure components being injected as part of this supply chain. Now, open source 5G is at the intersection of these threats coming from the software world and the 5G world. Just to highlight a few of the threats, we have a software and configuration related threats, meaning more software means more configuration that needs to be maintained. And attackers can modify those configuration, reduce the security and gain access to the network and install malware and create other risks. The other issue is network security, where if network devices are compromised through a network layer expert, malicious actors can obtain unauthorized access to the entire 5G network. Another new feature in open source 5G or 5G networks is the network slicing. And that creates the risk of improper network slice management that may allow malicious actors to access data from different slices or deny access to users of other slices. So that's a whole new aspect of security that needs to be dealt with. Then it's important to remember there are legacy communication infrastructure threats, so 5G supports all the security and the specification of the protocols of the 4G legacy communication. So in addition to the new threats, all the old threats are still in existence. Another aspect is the multi-access edge computing or MEK, the introduction of untrusted 5G components into the edge could expose core network elements to risks and that are introduced by software and higher vulnerabilities of these edge components. Another risk is presented by spectrum sharing, where 5G systems require a complement of spectrum frequencies to reach their maximum potential. This may provide more opportunities for malicious actors to gem or interfere with different bandwidths. Then finally there's the architecture of software defined networks where the architecture automatically configures routes and other network aspects centrally using an SDN controller. While SDN improves the network flexibility and ease of management, it also allows malicious actors to embed code in the SDN controller and applications to conflict bandwidth and negatively affect the operations of the network. So let's talk about what the Linux Foundation networking projects are doing to improve the security and what are the best practices. First of all, it's important to understand that there is no silver bullet. Making the software code available as open source is a good starting point, but it's not the whole story. There actually needs to be a holistic process that takes care of making the software more secure. The Linux Foundation networking views open source security as a continuously proven process that evolves as the project itself evolves in its maturity level and the phase of adoption by end users. So throughout the software project lifecycle, additional advancement are required to make the software more secure and that involves process definitions, security audits, and security threat modeling. Elephant projects aim to develop security best practices in several areas. Some of them are in the early stages of the requirement and the architecture definition, then that's when security is taken into consideration. It goes through the development framework that the developers use and the tools such as code scanners and S-bomb software builds of materials and it continues with vulnerability testing of the software and guidelines for secure configuration of the deployed software. This is all a group effort. It can be done by just one or two individuals. It requires the knowledge and expertise of entire communities. This is why under the Linux Foundation Networking, we have several work groups, task forces, and security committees that are dealing with improving the security of our software and the derived products. And that involves everything from the design phases, the development through the deployments and all the way until the software is decommissioned. We also try to track our security posture at all times and for that we use dashboard for continuous tracking of issues and trends related to security. When looking at the security supply chains, there are multiple actions that need to happen for that supply chain to be secure. So it starts on the left side as you see with securing the integrity of the source code. And that involves different actions such as identifying and securing the tools and the most critical components of the software and educating the developers on how to build better or more secure source code. Then it continues on the right side of this diagram with the building integrity or what is called the securing the software factory or how the software is produced. And that involves using tracking tools such as software builds of materials and also identifying critical parts of the stack and identifying attack vectors. And it turns out that most projects and organizations are not able to accurately summarize the software that is running under your system and especially its dependencies. So there is this diagram on the left that is coming from an actual comic script street, but it actually depicts the real harsh reality of where many modern digital infrastructure and software actually relies deep down on some obscure libraries that are maintained by some unknown individual who nobody ever met and that creates a serious security threat to the entire software stack. So I mentioned SBOM, but I would like to say a few more words about what is it exactly. So the National Telecommunication and Information Administration in the US defines it as a formal machine readable inventory of software components and dependencies and information about those components and their hierarchical relationship as you can see in the sample diagram below. SBOMs may include open source or proprietary software. So it's not something that is specific to open source software, and they can be either widely available to the public or be access restricted and viewable only by a few. SBOMs should include baseline attributes with ability to uniquely identify individual components because identifying components can be a bit challenging because there's might be some ambiguity of the library name that makes it sometimes difficult to identify which is which and who is who in the components. Most efficiently, the most efficient way to generate SBOMs is a byproduct of the modern development process, meaning integrating it with the CI CD process. But there are other methods may be suitable for older software where this SBOM can be generated manually. Speaking about the Linux Foundation networking projects, we've implemented SBOM for several projects, starting with one of the most mature and widely developed project in the under the LFN own up. So the community implemented SBOM generation, it uses a template of the SPDX format, and it is implemented using LF networking CI pipeline and can be easily leveraged by other open source project groups. Anuket another LFN project identified SBOM as one of the security measures for creating a robust telco infrastructure. This is already included as part of the project holistic security requirements specifications and any other places in this project. Finally, open daylight where the community working on this project has recently successfully added automatic generation of SBOM using the Cyclone DX format. This is expected to become available in the coming releases of this project. Another aspect of security I mentioned is the dashboards that help us stay on top of things and understand where we stand with regards to security. So the LFN networking projects make use of the Linux Foundation LFX infrastructure that provides security dashboards for projects and allows project to easily get onboarded to these dashboards and immediately get throws of information related to the security of the software. As you can see here, those LFX dashboards include several views starting with summary cards which highlight the trends and issue counts and it goes down to more detailed information that is project specific about the number of issues, number of issues resolved over time and how many open issues exist and so on and so forth. So we found those tools to be highly reliable and highly useful to determine our position with regards to security and this is something that is being constantly monitored by the entire community. Here are some of the other lessons we've learned through the development of the secure software and the Linux Foundation networking. First is that all developers should be trained on how to develop and acquire secure software. There is a training course available by the OpenSSF project of the Linux Foundation about secure software development. This makes software development develop their software to be secure by default. It's a highly recommended course available to everyone free of charge and has been already been used by many of our projects. The other tools that we're using is the OpenSSF best practices badge. Again, another tool offered by the OpenSSF project where projects can self evaluate and make sure they're following the best practices for developing secure software. There are many tools to find vulnerability and most of them can be integrated into the CICD pipeline of projects. So there are quality scanners and linters. There are security code scanners that do static or dynamic analysis. There are secret scanning to find out the use of secret in the codes embedded in the code. There are software composition analysis tools and many other tools, including fuzzers and others. There is a convenient guide again provided by the OpenSSF project from the security tooling workgroup, which lists many of those available tools and we recommend using as many of them for your projects. Then we realize there is a need for monitoring for known vulnerabilities in what you depend on. Each project should have a process defined for that on how to keep track on dependencies and how to respond when vulnerabilities and dependencies are discovered. There is a need to enable rapid dependency updates, which means it's best to use package managers and automated tests. So package managers can be things like language level, Python package managers, or container like Docker image managers. And there should be tests in place to make sure that all packages include the latest updates and patches. Another thing to pay attention to is evaluating the software before selecting dependencies. There could be all kinds of different ways to inject malicious software into open source libraries, so we have to be very careful about that. Type of squatting is a method of malicious actors to create vulnerable or insecure software packages and make them masquerade as legitimate software packages. So there's a need to pay attention to that. And in general, it requires a good review of what exactly are we integrating into our projects. The next thing is making it easier for end users to update our software. Meaning that whenever there is a security vulnerability discovered and we issue a fix for that, it should be easy for our end users to use the patch version, which means that we need to make sure it's easy to update our project. Usually it means that we need to have stable APIs that would make it less interuptive for our end users to change the version to the latest and patched one. And then we learned that there is a need to continuously improve. Attackers keep getting better, so the defense mechanisms should also keep track of that and keep evolving over time. A few of the lessons learned with regards to using open source software. First of all, some of the questions that we should ask ourselves is, is there evidence that the developers of the software we're using are actually working to make it secure and the list in the previous slide is a good place to start and see how many of those best practices are actually used by the software that we are about to use. Then you should ask yourself whether it's easy to use the software securely, meaning is all the default setting out of the box of the software component that we're using indicate that it can be used securely and that it is hardened. The next question to us is, is the software library maintained? We need to check for recent commits, issues, releases, and see if the project is actually keeps getting frequent updates in security and other aspects. Things like whether there are multi-organization working on the project, whether it's not a single company or a single organization project, all these indicate a project that is constantly evolving and constantly providing security updates. The other thing to look at is whether the project we're using has any significant use in the industry. Beware of projects that are not really used and therefore probably are not likely to receive frequent security updates and not likely to have security issues detected and identified. Another thing to look at is the software license. Another red flag is when the software that we're about to use have no license, that means it's not really an open source library and that can also indicate that it's not very secure, not receiving the right security updates. Of course, the best way is to evaluate the software using yourself. Remember, it's open source software, so it makes it possible for you to go in, look at the code and review the code level, the project that you're using and determine whether what you're about to use has the adequate security mechanisms that you're expecting. And last but not least, remember to make sure that you're acquiring or in most cases it's downloading the software securely and you're not subject to all kinds of possibilities of injection of malicious software through the way that you are acquiring your dependencies. To summarize the key takeaways from today, I think it's important to remember that all software is vulnerable to security threats and 5G networking software is no different here. The second thing is that securing network software is a continuous process. It starts with the software design in the early stages. It continues through the actual software development process, the testing goes on to the deployment and it should continue and evolve until the software is actually decommissioned. Unfortunately, there is no single flip switch to turn for turning on security. That means that we need to use multiple tools and multiple best practices. All of them needs to be applied to our software to make it more secure. And finally, as you've seen, the Lean Foundation offers a wide range of tools to help developers build secure software that starts with training, goes through badging and ends with dashboards that allows you to see how actually good you are in terms of your secure software. So I hope you managed to learn from our experience today about developing secure software and I hope you find practical uses for that in your software projects. Thank you.