 So I'm going to go through the presentation even though I do not have a way to share it. So basically I'm going to talk about the software supply chain. The agenda is going to be software supply chain, the attack surface of the software supply chain, commercial of the shelf software, as well as commercial of the shelf, you know, software shared open source software. Okay. Then the trends in software supply chain compromises, evaluation of data on actual attacks and the solar winds hack, which is obviously the hack that brought everybody the attention to the software supply chain and the special case of open source software and some mitigation measures, especially for, especially for hyper ledger. Okay. That's the, so first thing is software is ubiquitous, which obviously means that it is highly pervasive. It's everywhere and it is on 24 seven and obviously software is evolving fast and it's highly complex. These are all very simple statements, but they have tremendous implications. So what are the consequences? The consequences are because of the high pace of evolution of software. Most enterprises do not develop in house software. They get commercial of the shelf software or commercial open source software. They also, it is also based on the principle of reuse and outsourcing complexity. The world's appetite for software is ever increasing. Somebody said that software is eating the world, but I think it is more that the world is eating software and having it as a greater part of its diet. And because of this, the world has many cases of indigestion and poisoning and major, major organs can be affected. These are all metaphors, but in the end, the metaphors make sense when the, the abstraction of the metaphor and the actual use, actual observed problems in the world coincide. Now, in terms of the software supply chain attacks, there was a well-known thought experiment from Ken Thompson in 1984. He was speaking as a Turing Award honoree, and it was a Turing Award lecture, and he talked about how a C compiler can be hacked to insert a Trojan horse leaving no traces in the source. Essentially, the source is modified to allow certain passwords, you know, which are not in the list of approved passwords to the sources hacked, make the changes made, the C compiler itself is written in C, so it is compiled, and then the source is put back to its original, you know, without the hack. And so the no traces of this hack are found in the source, no static analysis, no dynamic analysis, I mean, no analysis of the source would let you know that the compiler has been altered. As the level of the program gets lower, this is what Ken Thompson said. Ken Thompson, of course, is the duo of Thompson and Richie who created the Unix operating system and also the C compiler. And as the level of the program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect. So it's already known that in 1984 that you can do this. You can actually hack the supply chain, the actual, you know, software that builds the other software and insert a bug into the compiled program. He also made another point which is that you have to trust the writers of the program rather than trusting anybody else. So, and he made another point which was the crime of breaking into a computer should be as bad as a crime of breaking into somebody else's house or stealing a car or something like that. But obviously people can do this frictionlessly from afar and they do not face the same consequences. Now we go to the SolarWinds or IT management product which was backdoor to insert malware using a component with an innocuous name. Its name is, name was taskhostw.exe. This hack was codenamed SunSpot by the analysts. So anyway, people are offering me suggestions on how to make, you know, share the screen. But I'm not, since I'm on the other tab where I'm looking at the presentation, I have no way of really doing this right now. But anyway, I go back to the SolarWinds Orion IT management product which was ubiquitous again because it was used by many, many enterprises. The malware was codenamed SunSpot by the analysts. It is not the name which was in the software itself but because of the word SolarWinds, obviously it was called SunSpot. The SunSpot does exactly what Ken Thompson said it, you know, was talking about. Basically, it monitors the running processes to see whether MSBuild.exe is running and then it replaces one of the source files to include the backdoor cord. Inserting, of course, things like pragma warnings off and turning the pragma warnings on and off which I've done myself in many cases to avoid spurious warnings. And several safeguards were added to SunSpot to avoid the Orion bills from failing. Orion was chosen because it is used extensively in enterprises, both government and private. Actually, and of course after this hack and after the, so the primary hack must have involved compromise of some sort and allowing the attackers into the SolarWinds build server which is where all this stuff was being done. And since it was extensively distributed to more than 18,000, well, the estimate is more, between 18,000 and 30,000 enterprises used the hacked version of the software. And I have these beautiful diagrams here which talks about the sunburst as a continuation of attacks that had already happened and were clearly documented. And in this, the software supply chain stack which was, you know, goes from system design, implementation, iterative testing and deployment, the compromise could happen at various points. And there were well-known pathways, account access compromise, stolen certificates, flawed cryptography, code injection, forged certificates, unsigned and broken signature systems. So all of these could have been involved. But sunburst was very interesting because it not only compromised, I mean, as is usual with supply chain attacks, it not only compromises the build server of a commercial off-the-shelf software distributor, but obviously it goes into every place that software is used where they could install other, they could drop other malware and hence break into all of the customers of the attack. Obviously, the open source software is is a very high on the list of software to be compromised because it has such a wide reach. We will go into that in detail later, but right now I'm talking about the fact that the attack is not on the solar winds, but on other systems, mostly the customer systems. And using that, the attack spread laterally to Microsoft, well, identity and access management systems, using which they were able to do compromise a lot of the cloud system and they were going after specific intelligence like emails and other very sensitive topics. So this is a nation state, obviously, attacking the infrastructure of the United States in this case, but it also spread to other countries. So the main thing to note here is that many of the pathways used are where very commonly known, never fixed or never adequately addressed, and the software took the software took a long time to properly launch. And so the obviously the attackers were very discreet in in covering their tracks and the attack, well, the word attack implies or even sunburst implies a action that takes place in a very short period of time, but this this should really be something that should be used to describe something that happened over eight months or 10 months. And that persistence and patience and covering the tracks is what helped the attackers gain control over so many, so many systems. If you go back to the if you go back to the actual number of organizations compromised 18,000 or so, they only concentrated on a few, obviously, they didn't want to attack 18,000 organizations. 425 members of the US Fortune 500, systematically important vendors like Microsoft and Intel and nearly a dozen US federal government agencies, including the departments of Treasury, Homeland Security, State and Energy, as well as state and local governments. So this is pretty much the entire software infrastructure of governments and private companies, when private companies say, oh, we are, you know, the governments get attacked because they have bureaucratic and so on. That is not true. They, you know, out of Fortune 500, 425 members have been attacked. And the Linspin services like identity and access management software from Azure, Azure Active Directory were compromised to gain access to many user email accounts. It was a cloud-based compromise as well as a sign of a state actor with time, money, patience and discipline. More than an IT failure, this is a strategic failure for the United States. That is what some of the references that I have quoted say. Now, coming to open source, open source software is like the SolarWinds Orion because it is used everywhere. And if you want some numbers, I can say that about 1.5 trillion open source software downloads with requests were expected in 2020. And many enterprise software components have a significant portion of their software is open source. And, you know, there is 430 percent year over year growth in cyber attacks targeting open source software projects. Nearly 40 percent of all NPM packages rely on code with known vulnerabilities. You know, this is no way to proceed because this open source, as you know, is a community resource just like a well. And that's why this presentation is called the Poisoned Well. The well is where everybody goes to drink and obviously if the well is poisoned, everybody gets affected. So software, open source software is becoming more and more ubiquitous. Not only regular software, but, you know, open source. So it is an attack vector and we should be aware of it in hyperledger because we create, we are the largest consortium of DLT technology open source software. But it's also well known that, I mean, not well known, but, you know, the statistics tell us that there is a separation between the people who act and the people who do not act. That means exemplary projects are 530 times faster in updating dependencies and finding out the latest vulnerabilities that have been released in their dependencies. First of all, the number of, the first thing to do is to create a software bill of materials, SBOM, which is similar to the regular bill of materials for any product. So that if there's a problem in any of the supply, any of the components of the software, of the bill of materials, then you can trace it back to the source and you can say, okay, you've got to have either a new component or a way to address it. So we can start with a software bill of materials, which is nothing but a list of all the dependencies, obviously not built by humans, but by using SCA, Software Component Analysis, like WhiteSource Bolt, and you can actually install it in your GitHub repository. I have forked several of Hyperlager projects. I don't want to go into the details of what I found, but you can actually install WhiteSource Bolt and do a scan of the components and if the components in any of the dependency chains are found to be compromised, then the WhiteSource Bolt would create an automatic issue for you so that you have to fix it. And SBOM best practices, tools and expertise are being developed by NIST and Hyperlager repositories should have a, develop a software bill of materials as part of our security practice and automate this using tools that are freely available. This is the first thing that we can do and I have unfortunately run out of time almost, so I'm going to go back to you guys and see whether you have any questions or anything that that I can hope to answer in the next few minutes. And I know that 22 people are watching. I'm sorry that I was not able to share the screens. It started, anyway, I don't want to complain about this, but it's also very early here for 430. So please chat and let me know how you like the session, whether it's, you know, I will end the session, I will leave because I don't know whether there's any other way to end the session. I hope you guys got something out of it. Please put your stuff on chat. If you, if you did, that would be a great thing. Thank you.