Host Intro (Gene Kim)

Gene Kim: To set up the next talk, I want to share some of my reactions to the recent XZ incident, which my friend Daniel Miessler called movie-level shit, forgive my language. In other words, it was a software supply chain attack that almost resulted in a remote code execution vulnerability in OpenSSH, detected only by accident.

Daniel called it movie-level because it was an epic long game featuring accomplices, elements of social engineering, and an attempt to compromise, oh, I don't know, potentially every server on the planet.

I think stories like this underscore some pretty sobering problems that anyone using open source software faces, which, by many estimates, are 95% of all the software we run in production.

So up next is Boris Cipot, Senior Security Engineer at Synopsys, to teach us about the epic level of cybersecurity issues that every modern technology faces. Cool.

Boris Cipot

Boris Cipot: Thank you very much for taking your time to listen to me today. I will talk about cyber threats that became, or become, unwanted real-life Hollywood blockbusters. My name is Boris Cipot, and I'm the Senior Security Engineer at Synopsys.

One thing I have to clear out before we start is: by attending this presentation, your data will be shared by the organizers of this event, and Synopsys may contact you about products and services you may be interested in. You can unsubscribe also at any time.

But now let's get back to the presentation itself. We will try to understand the threats, learn best practices on resolving the issues, and see how the problems that we have today in the cybersecurity space can be addressed. Of course, it's not something that started to happen today. This is already going on for years.

Why I want to present it as a Hollywood blockbuster: well, I myself enjoy a good cybersecurity Hollywood blockbuster where you have the cyber criminal or cyber expert that tries to hunt the criminal, and you have then the police guy that is protecting somebody and hunting the bad guy in the end. And the worst thing that we see in those movies is how a cyber criminal can bring down whole states or cities or the infrastructure.

Many times we feel that this is exaggerated, that this can never happen. On the other hand, we are living in those hacks. We are living in those times where software is dictating our daily lives, even deciding on our care and health. Therefore, it's really important that this software is kept safe.

We know about Heartbleed. As I said, those situations are not coming from today. There was an OpenSSL library vulnerability that was leaking out the data already 10 years ago. Why I decided to show it today: it was, in April, the 10th-year anniversary of this vulnerability being known. However, the vulnerability at the time when it was known in 2014 was already living in systems for several years.

What about Log4j? For sure, you heard Log4j in 2021 or December 2021, where even the news said that the internet is now on fire, because one component that was shared in almost every web application, every webpage in the world, was now at this moment vulnerable and getting every server exposed.

But both of those are something that can happen in software. It can have a vulnerability. However, as Gene mentioned, the XZ Utils is now the real blockbuster here. It's not something that happened because a developer had a bad day and introduced a vulnerability into the code by mistake. No, XZ Utils was actually premeditated. It was planned. It was started three years and then maintained as a backdoor in order to attack when the right moment would appear.

This is the scary moment, because XZ Utils, a really well-known library that is used on almost any server in the world, has now a backdoor that the cyber criminal can attack.

If we think about what those backdoors or viruses or malware actually are, where do we start? In the beginning, malware was something that was there protecting software, or that was known. When you were being infected, you knew that there was an infection, that there was something going on with your computer that was out of the normal. The infection was visible and you could react to this.

However, later on, when the motivation became fame, where young software developers and hackers wanted to make their name known in the world, they were still signing their viruses. However, they did not want to harm anybody. They just wanted to take advantage of some resources, like our Joseph here, or, for example, creating viruses that were showing off their capabilities.

But as you know, sooner or later it became also that the actual motivation was money: monetization on what hackers were doing. Criminal organizations started to take over the knowledge. Whereas, of course, being that they needed your computers for botnets or any other operations, the infections started to be hidden. The viruses were not anymore shown. They were under the radar so that you don't know that you're infected, but could be having an infection where a botnet administrator could use your computer to hack other computers or to spam them or to DDoS them. All those things started to become clear.

Now in today's world, we have all sorts of motivations, be it money, hacktivism, politics. All those mix and match somehow with cyber criminals and states attacking other states, and cyber war, if I may say it, became something that is also used in any way possible in order to gain advantage over the victim or get their possibilities down.

Which parts are here at stake? It's not only our home computers. We are talking about companies. We are talking about critical infrastructure like transportation, infrastructure, power services, and banks that are here under attack.

Again, we came to this: hey, he's again talking about blockbuster. But that's not so out of proportion if we think about the points that even those critical infrastructures were attacked already in the years like 2003 and 2004 by viruses or worms that we knew back then, and they could bring down those infrastructures.

Now again, you might think: hey, but we are so far away now. We are now 20 years away from those points. We for sure have to be better in what we are doing. And yes, we have certain things done better now, and we are keeping our eyes more opened. However, there are still so many attacks happening, not because we would like that to happen, but because it's just so that software, being the crucial part of our lives, is unfortunately also the weakest link in what we are today having.

Those are just some of the attacks that are listed, and maybe a percent of them has made it into the big news. But attacks to different organizations, to different critical infrastructures are happening daily. If you want to read more about this, there are different webpages that are listing those attacks. From that perspective, you can make your own picture also about this if you think I'm over-exaggerating.

Now to the question: how did it come so far? Why can't we get this under control? Again, we have to start in the past. Previously, software development was only proprietary source code. We knew what we were developing. The complexity was kind of low. We had long development cycles. For you that are in my years, you know that we were talking about waterfall and we were developing in monthly cycles, where we were talking about three-month milestones and such things.

There was a lot of time to test, to prepare, and still we did not get it right every time. There was no connection to the internet or other networks, and there were just a few platforms to support.

Now, if you think about this from that perspective, every PC, every mobile phone, everything is connected to the internet all the time. Hell, even our cars are connected to some backends. And if I say now like this, we have operating systems on laptops, we have then mobile operating systems, we have car operating systems. There are many platforms that we have to support.

The complexity of everything, the velocity of everything, is higher. We are delivering software in weekly or biweekly phases. We have languages and networks to support. We are using open source in our software. It's not only the proprietary part that we take care of, but also software that others developed that we just use in our software.

With all of this, of course, there is more risk to expose or to use vulnerability, and hopefully we will know something about it before it's a problem. But many times, as in the XZ Utils, you don't know until somebody notices it. This means that vulnerability can live in your software, live on your mobile phone for years to come before somebody will react or recognize it.

Software today has so many layers. It has open source components, proprietary code, APIs, web UIs, everything that can be connected to everything that somebody can explore. This makes it harder now to also test this software. It's also harder to test because all those layers, all those levels have their own complexity that comes with it. You cannot all test it in stateless usage, but it has to be tested even when it's used in real life. There are many problems where these modern applications can prove to be a high risk.

Even though this can happen, that you are using a component that is vulnerable, either by introducing third-party libraries or code reuse or whatever, for example, imagine you're using a third-party component. You are not only using this component; we are calling this a direct dependency. You're also using every dependency of this dependency, which are transitive dependencies. You can be using directly one of them; this one is using 15 further components, which means that the rabbit hole in which you're going is far deeper than you think at first. This is the other complexity: usage and reuse of third-party components.

The problem can also be that those components have vulnerabilities. Those transitive ones, they go out of maintenance, and then vulnerabilities start living further.

Why now open source monitoring is important: there is legal risk, security risk, and operational risk. When we are talking about open source, you have to know that today's applications are even up to 96% of those applications have open source components introduced in them, whereas the majority of the code in those applications is open source.

We have seen that license compliance risks are not taken care of well enough for many of them. This means that also the applications that you're writing, if you don't have legal compliance, your intellectual property can be taken to open source. So it's still critical.

If we look at open source vulnerabilities contained in those applications, we can still see that many applications are still containing vulnerabilities, which means that 84% of all codebases contained at least one open source vulnerability.

Think about what AI brings into the whole mix, where we are using code provided by AI. Who is testing this code to be without any vulnerabilities when we are compiling our software and bringing it to the customers? All those things are the complexity companies are dealing with today when developing software.

And now how to resolve the issue. One of the issue-resolving things are standards. The U.S. first started the executive order on improving the nation's cybersecurity. They started in 2021, where Executive Order 14028 was introduced. The main point was to create an SBOM so that every user of software knows what he's using so that he can react on it.

Also on the EU ground, we have now the Cyber Resilience Act that also demands a usage of SBOM, or software bill of material, that shows which components are used in any software product so that the users can react on any vulnerabilities.

Many times I see that customers just buy a tool and think, hey, this will all be well because source code in and the tools will do their magic and perfect software will come out. Well, it's not always like this. You have to think about the capabilities that you're introducing. You have to educate your people, and you have to also use managed services and pen testing in order to have the whole picture on what your software is delivering.

Through the development lifecycle, different tools have to be used. All the organization has to be brought into it, and you have to develop a sort of community sense on how to deal with those things. Take on the challenge: plan, identify untrustworthy software, develop procedures for problem remediation, and please call it as you wish, just get on the DevOps culture, do it right way, and integrate the procedures at every step of your process.

Please reach out to me if you're interested in any of the topics. Thank you.