 Today we're talking about log for j or log for it. And by now you've probably heard the log for j vulnerability. So let's talk a little bit about what that is. We have a string that we inject and it could be injected into any form on a website. And this malicious string is then executed by the log for j software. So we have an injection attack where we can put a string in and anything that log for j a logging software would normally process and log will then be executed. So here we have an example of connecting back to a malicious IP address and executing some sort of exploit. This is a very basic log for j attack string. Now you can do a lot of things with this data ex filtration remote code execution. This opens up a lot of different vectors of attack. But just being able to inject a string is not why the log for j cyber attack is interesting. What's interesting about it is that log for j is in a lot of software. So this is where we come back to software supply chain. And you've probably heard about supply chain attacks in the solar winds cyber attack that happened not too long ago. The supply chain had malicious code injected into it solar winds used code that was injected and then spread that out to all of their customers log for j is a little bit different in the fact that we have a vulnerability in the software and that software just happens to be used by a lot of different companies. The big issue why everyone is concerned is because log for j software is used in a lot of different programs but also because of the way that we package software now. So we still have a software supply chain vulnerability. So the way that software is packaged now I have the log for j package and then I want to put that into my program. I'll call my program X my program X might have some library in it that another program wants to use. So they might include my program X inside their program Y and to top that off they might also use their own version of log for j in their software. My software X has log for j their software Y has log for j and and their software is using my software. So they're also dependent on everything that I'm dependent on. So here's where the issue comes in. Imagine the company that makes software Y they understand that log for j is now vulnerable. So they fix their software they make sure that it's not vulnerable anymore. They have no control over my software X. So they have to wait for me as a company to update my software make sure that log for j is not vulnerable and then push out an update after I push out an update they have to update their software to be compatible with my new version of the software. What's happening with supply chain attacks is if we find a big vulnerability like this, everyone across the entire stack has to update their software. But the software that's used at the lowest levels have to update their software first and then the second level gets updated second and then the third level gets updated third and so on until everyone across the entire chain has had updated software. So this becomes really difficult because you have to wait a long time for all of those companies to update their software before you can actually update your software. So a lot of software these days are very modular. We use a lot of code from other sources and that means that all of these packages are related. So it's not just one company has to update their software, it's 20 companies have to update their software and then I can update my software. That's why log for j was such an issue because it was easy to do. There's so many packages that are using some version of log for j. It's really difficult to get those packages updated. That way you can update yours. Another big problem is that a lot of companies, whenever they're developing software, they don't keep what's called a software bill of materials. That is, they don't keep a list of all of the dependencies they have and all of the dependencies that those dependencies have. So they don't have an inventory essentially of all of the software and all the libraries that are being used in their products. If you don't have a software bill of materials, you don't know where vulnerable versions of log for j or any other software that you have might be. So if you have 1000 systems across your network, and each of them might have say different versions of a piece of software, if you don't have that inventory, you don't know which of those 1000 systems are vulnerable, you don't know what pieces of software in those systems might be vulnerable, not having that inventory makes remediation very difficult. And eventually it makes incident response very difficult. So in the case of log for j what we ended up seeing again, is that a lot of companies don't know what software they're using or at least what software dependencies their dependencies have for your network or for your clients, create a software bill of materials for them. In the next two videos, I'll show you how to scan systems to build a software bill of materials. That way you know all of the software that's being used in the system, plus the dependencies and then check those dependencies for vulnerabilities. Log for j is not the only dependency software that has vulnerabilities. So I'll see you in the next videos. Thank you very much.