Well, it's another great day here at info sec. And we're in the skills learning path for the 2021 OWASP top ten. And we are looking at security risk number eight, software and data integrity failures. So what's that all about? Well, let's dive in and let's check it out. All right, here we go. Software and data integrity, so this is a new category for the 2021 list, right? So it has not been there previously and this is all about software updates, critical data, CI/CD pipelines. And making assumptions about those things without verifying the integrity of those updates or of that data, right. And so you can see there that this actual or this particular risk is one of the highest weighted impacts from CVE/CVSS. We talked about CVSS in the previous video, that's that scoring system, right? And so when you look at CVE data, CVSS data, we'll see here in a minute from the data factors that the impact to the business for this particular risk is extremely high. But again, kind of the fundamental idea around software and data integrity is that your organization, your application uses software, of course. It has data that you store or that you use and if you cannot verify the integrity of that data or the integrity of that software, then it's going to cause a lot of problems downstream, if you will. So we'll dive into the details of what that looks like here in this video. All right, so software integrity specifically, right? Software and data integrity failures, they relate to code and infrastructure that does not protect against integrity violations, okay? So it's like I said a second ago, if you've got code, if you've got infrastructure that you're using. And you're not validating and you're not providing integrity on where that code comes from or where that or how that infrastructure is put together, then you're going to have problems, right? So you can see there in that in that second bullet an example is where an application relies on plug ins. Libraries modules, all that from untrusted sources or untrusted repositories or untrusted CDNs, content delivery networks. And so if an application is relying on that and we've gone over this a little bit in previous videos as well. If you've got third party or untrusted libraries components, then that's then that could introduce problems into your own application, right? And so there needs to be integrity around the the software, the code itself, but also the infrastructure that you're building your application on. You can see there an insecure CI/CD pipeline, that's the continuous integration, continuous deployment or continuous development. It's the idea that you are continually developing and deploying and integrating your software. I mean, there's companies that will push new production code up to thousands of times every single day. So it's this constant moving process. And so whenever you've got a pipeline like that, that is potentially moving that quickly to provide updates, I mean there's obviously good things associated with that. Because if you have an update you need to push, it's like well hang on, let me wait about about three seconds and then boom, I get to push the update right? But the problem with that is things are moving so quickly that if you're not verifying the integrity of the code and if you don't have a solid CI/CD process mindset. That whole thing, then you can be introducing problems into your application, into your code. And so anyway, so you can see there that insecure pipeline can introduce potential for unauthorized access, malicious code, all that kind of stuff, right? And then you can see down there, then the next bullet down many applications include auto update functionality. So this is again when you talk about automation, when you talk about applications that are moving very quickly in today's world. Then the automation, the auto update functionality becomes a necessity, right? And so if organizations say, hey we're just going to auto update, then those updates need to be downloaded from a known good place. There needs to be integrity verification from the software updates. And so anyway, so if you're going to apply that to your trusted application, if that your application was trusted and you validated that, but that's a whole another thing. You need to validate deployment or post upgrade, have we kept the application trusted. Then, if you apply an untrusted or software that has not been verified to have integrity, if you've applied that to your previously trusted application, then suddenly the application is no longer trusted, right? So that could be a problem. You can see there, what could happen is attackers could upload their own updates to this whole pipeline. So if you're pulling updates from a source that you don't verify the integrity, then that gives the attackers an open door or a pathway into your application by infecting that. It's like they infect the source if you will and then you pull from that source and you put their bad stuff in your application is kind of the idea. So that happens and it's, and I will go into some details on some scenarios, some stories where that has actually caused a lot of problems, right. Okay, so let's look at the factors here really quick. I know I mentioned the weighted impact, the impact score is one of the highest that the Os Group saw on any of these top ten. And you can see there, well, it's kind of in the middle, the average weighted impact 7.94, it's a big number because that, again, that's out of 10. But if we go to the left and we look at CWS map, there's ten CWS, the incidents, the max incident rate and the average incident rate, not as big as we've seen on some of the other ones. These are the applications that are actually vulnerable to those one or more of those CWEs. You can see the exploit number is almost seven, which means that these are not that hard to exploit this particular risk. And then of course the impact is almost eight, which is really big, you can see the coverage, the max coverage and average coverage, those are pretty big numbers. And those are applications that were tested against the CWE s and then you see a total occurrence of 47 almost 48,000, that's out of again, almost just over 500,000. So not a huge number there, but still a lot of occurrences and then CDEs just over 1100, not the biggest we've seen, but still that's, if you look at it from just a pure numbers perspective. That's 1100 vulnerabilities that Attackers would have, have access to get into applications based on this particular security risk, right? So it's a big deal, it's a thing we need to be looking at. Okay, here's just kind of a picture of what could be happening here. You've got application users that are accessing an application there on the right. And then that application is reliant upon third party libraries or plug ins or modules, whatever it is. And so if if an attacker comes in and says, hey, I'm going to infect a particular plug in. Via a variety of different ways. Then suddenly that plug in is infected and that application depends on that plug in. And so now, the application is infected, and then that bug gets passed on to the application users, and so then that creates problems. So that's the way that some of these things can spread when it comes to the untrusted or the software problems that don't have the integrity check. So again, if you had an integrity check when you're looking at that plug in, then then presumably you would be able to say, hey, there's been a change there. It's been infected, and I'm not going to rely on that plug in or I'm not going to rely on that version of that plug in whatever it is, right? So that's where there needs to be that software and data integrity check before you start using it in your application. Okay, so here's kind of a scenario, it's a similar type thing, and we've talked about these in the past, these components with vulnerabilities, right? Where you have a camera, or maybe a wireless printer, or maybe some kind of a TV box, or a home router, or whatever it is, right? They have a device firmware on them, and they don't typically verify updates via signed firmware, right? And so if you have the idea with signed firmware is that the manufacturer of that firmware to maybe a printer, let's just pick on the printer this time. Then the manufacturer of that firmware it's going to say, hey, here's an update to the firmware, because there's been a problem or whatever it is, or maybe there's just new functionality that you want to take advantage of. Then the manufacturer will update that firmware and then you can be notified via maybe an email list, or maybe you go check, or maybe they notify you, or whatever it is, but nonetheless you're notified of the new firmware. And so if they don't sign that firmware, then you're not quite sure where that firmware came from, right? So to say it differently, if they do sign, they use some sort of a digital signature, then that provides the verification of the fact that firmware came from the trusted source, right? From that actual organization. But in the world today, a lot of these firmware upgrades they don't get digitally signed to prove that they came from a trusted source, and so this becomes a growing target for attackers, right? So now, attackers can come in and say, hey, I will provide the firmware for that wireless printer that you have sitting on your desk or whatever, but in that firmware, so it's going to do the thing that you wanted to do. But I'm going to insert some sort of malware as well, and presumably they're going to say, hey, I'm going to put in something that's going to make that device join a botnet. So that then I as the attacker, have access to this network of bots, which that printer now would be one if it got infected with this botnet malware. And then the attacker could use that as part of this massive volumetric dots attack or things like that, right? And so anyway, but all of that happens because the firmware was not signed to verify to validate that it came from a trusted source, and so that gives the attackers a way in, right? So anyway, you can see they're kind of at the bottom of that little paragraph. It's a major concern, because there's really no mechanism to remediate or any of that other than to fix in a future version, and wait for the previous versions to age out. So anyway, so that's [LAUGH] It kind of puts you between a rock and a hard place. And sometimes the story in this cyber security discussion in the world today is that it's like, hey, I can't necessarily give you this great news on, well, hey, well, here's exactly how you fix this big problem. But rather just say, hey, at least let's be educated on the problem that is out there so that we can be aware of it and do the things that we can do, and understand that sometimes we can't do as much as we would want to do, right? So hey, maybe one day you'll own the company that provides the firmware updates to these IOT devices. And then you can say, hey, we're going to make sure that we digitally sign all of our firmware updates and that kind of thing, right? So that's part of the answer as well. So let's be the change that we want to see in the world, right? All right, but that is a scenario that happens in terms of software and data integrity failures right into these devices. Here's another scenario, and this is the same type idea, but I'm going to talk about the solar winds of attack that happened specifically. Well, it depends on when you watch this video, but it happened a while back, let's just say. And so you have this company called solar winds and they provide network monitoring and visibility tools that you can download their software and deploy it on your network. And then you can see hey, how's my network doing? How's the performance? Do you have any places that are problematic, that kind of thing? So that's the essence of what the solar winds technology does. And so obviously they have software downloads that you download their stuff and you put it on your network on your machines, and then it can kind of look around and see everything, right? And so solar winds has become a very popular network monitoring tool that's in use with thousands of organizations. And a lot of these organizations are really big organizations that provide some really, really critical [LAUGH] Products and services, right? And so, I mean there's banks, there's government organizations, there's like huge cybersecurity firms that use this solar winds process or the solar winds technology, right? And so what happened specifically with solar winds is that the solar winds of organization has a company that develops software and the company has a secure building update integrity process, so they have actually done. They say, hey, we want to make sure that there's integrity in the build of new software and the update of software and all that stuff, which is great. But even still attackers were able to get into the software build and software update process, right? And so the attackers injected malware into the build and update process for solar winds. So then solar winds would say, hey, as far as we know, as far as we can tell these updates that we're pushing to all of our customers, they're secure, they have integrity, all of that stuff, right? And so what ended up happening is you can see there for several months the firm, solar winds distributed a highly targeted malicious update to more than 18,000 organizations, right? And then around 100 or so we're like largely affected. And again, this included the Department of Justice in the United States, many of the different US government departments. But one of the companies that was affected by this was a company called Fireeye, and Fireeye does a lot of like red team, blue team penetration testing. And what fire I would do specifically, is they would come into an organization and say, hey, we have a set of offensive and defensive cyber attack tools. And so we are going to attack your organization, and we've got different tactics and techniques, and procedures, and all that. That we're going to use to attack your network, and we have our certain toolbox that we use to attack, right? And then we're going to run our attacks and we're going to give you the report, we're going to tell you, hey, this is where we were able to get in and where we weren't. And this is what's good and bad, and just all that stuff, right? And so what happened was, this the attackers that attacked SolarWinds, they infected the SolarWinds update with their malware. Well, solar winds pushed out that infected update to the organization FireEye, right? And so now the infected update software is sitting in the FireEye organization. And as soon as they went through their updates to say, hey, there's a new update for SolarWinds, right? Then we need to update to this latest and greatest. And so they went through the the change process, and whatever process they have over at FireEye, to get on the latest and greatest update for SolarWinds. Well that included this infected malware, or this infected software, right? And so, anyway, so then the attackers were able to use that infected software to gain access into the FireEye networks, and start to steal those packages that FireEye uses to go and attack other organizations. Again, I mean, FireEye was doing it to do good things, to show companies where they're lacking in their security. But what the attackers were able to do is say, okay now, hey, now I know exactly how FireEye is attacking. And also I can grab these reports from companies that they've attacked, and I know exactly where the weak spots are. And FireEye by the way, is a big organization that has a lot of customers to include government organizations and all that, right? So now these attackers, because they infected the SolarWinds update process. They have been able to deploy their malware to companies like FireEye, and the department you know, US government different departments. And so they're able to look at their stuff. But then again, via FireEye, they can go out and reach into the customers of FireEye, and see exactly where they're weak on these different attack vectors, and all that, right? So it became this massive story, and of course FireEye was none too pleased with SolarWinds, because they're like, hey, SolarWinds, you gave us some infected stuff. So I don't know where that stands frankly today, but it's a frustrating thing, right? But all of this happened because of the build and update integrity process of the SolarWinds update was infected by attackers. So not a good thing, right? Not a good thing. All right, so here's just a quick little of article snapshot of the US is readying sanctions against Russia, over the SolarWinds cyberattack, right? And this massive attack, it's a huge deal, it's exactly what I said. I mean it hit a lot of very very high value targets like very notable targets, and that's why it's such a big deal. And you can see there the US is going after Russia in terms of, hey who were these attackers specifically that infected the SolarWinds update? So the US is saying here that it's Russian attackers, and they're going to try to get after Russia for doing this thing. Here's just a quick little snippet from that article. SolarWinds, a major US technology firm, was the subject of a cyber attack. This thing went on undetected for months, right? Foreign hackers, top US officials believe are from Russia, we were able to hack on this thing. And so you can see that there's private companies like the elite cybersecurity firm, FireEye upper rational line. So again FireEye is one of the customers of SolarWinds, right? The upper echelons of the US Government Department of Homeland Security, the Treasury Department. So these are some high value targets, right? And so you know, the US government, you see down there at the bottom, it's ready to impose sanctions on about a dozen Russian intelligence officials over their role in interfering. Well, it's for a couple of things, I guess it says here interfering with the presidential election and the SolarWinds attack. So it's anyway, this is how these things make headlines, right? So, you don't want your organization to be in the headlines, because you've got some kind of software integrity problem. But that's the nature of this security risk that we're talking about here in this video. Okay, so how do you protect yourself from this? You can use digital signatures, right? Or similar mechanisms to verify that the software or the data is from an expected source and has not been altered. So this gets back to the digital signature. This is the signed firmware thing that I was talking about earlier with the IOT type devices. Again to be fair, the SolarWinds attack that was from a trusted signed that whole thing. So is it's not a foolproof type situation, but that also doesn't mean that you should just throw your hands up and say, well then I'm never going to use digital signatures. Right now you should, you should absolutely sign your stuff and use digital digital signatures for software, and data downloads. Okay, so the next one there ensure libraries and dependencies like NPM or Maven, they are consuming trusted repositories. So if you need to consider host an internal known good repository that's been vetted. So all of this just points back to as much as you possibly can, know the source of the software that you're downloading. Know the integrity or the process has integrity built into it, that the software that's being developed by one organization that you're downloading, has not been altered. And it is from that actual trusted organization, right? So that's on one hand, you can see here in that third bullet ensure that the software supply chain security tool, like the OWASP Dependency Check or OWASP CycloneDX. Those are a couple of good tools that you can use. You can use that to verify that components don't contain vulnerabilities. So on the one end you're saying, hey, I want to do everything I can to make sure that the software I download is from the organization that I expected to be from. And that it has not been altered in the transmission, or the download process from that organization to me. But then once it gets to me, I'm going to run some stuff on my own network on my own applications, like the OWASP Dependency Check or the OWASP CycloneDX tool to scan my network, to scan my application. To say, hey, are there any known vulnerabilities on what I just put on my network or in my application, right? And so that's another piece that you can do, just to double check, right? And you should do both of those things. Okay, you can see the next one, ensure there's a review process for code configuration changes to minimize the chance that malicious code, or malicious configuration could be introduced into your pipeline. So again, this is the review process for the configuration change, like once you change the code, then is there a a review process post code change? That you can update or that you can try to minimize the chance that malicious stuff has has come into your application, right. You can see there the next one, ensure your CI/CI pipeline has proper segregation, there's configuration, there's access control. And so, this gets into just compartmentalizing a bit where if one thing gets infected, is it going to be able to reach out. And just in fact everything or do you have segregation from a process perspective? And also from just an architecture perspective of your application that this malware, this malicious code is not going to be able to spread everywhere, right. So look to do that wherever you can. And then down there at the bottom this is kind of a. We've talked about this a little bit but ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without some kind of integrity check or digital signature. Or make sure you can detect any kind of tampering a replay of the serialized data. This one by the way. If you watched the 2017 OWASP top ten, there was one of the risks on that top ten list was called insecure de serialization. And that one is no longer specifically a risk in the 2021 list but it's part of this. So it's kind of been wrapped up into this larger, untrusted, an unverified software type conversation, right. So, but it's still a problem, this insecure de serialization. So, but it gets back to the idea that if you have unsigned, unencrypted serialized data that's sent to untrusted clients, that's going to that's a problem. So, don't do those kinds of things, but that's an area that you need to look at and check on and make sure that you're not making that mistake, right. Okay, so a few resources to kind of wrap this one up here that you can see there's a cheat sheet, their infrastructure as code security cheat sheet. There's de serialization cheat sheet from the owasp organization. You can see there's a safe code.org, software integrity controls, that's a good resource to look at when it comes to this conversation. And then you can see down there at the bottom there's an NPR story about the solar winds hack and we talked about that in the in the video today. But again, when you talk about software updates and the integrity of that do everything you can to check the source of the software. Do everything you can to make sure that there's integrity built into the process. And then once you deploy that on your network and in your applications and you use those in your applications, then do these dependency checks. Do these checks to make sure that hey, I'm looking to see if any malware has been added or if any kind of vulnerability has been added. Because of these software, either a software download or just even a third party library or plug in that I'm using that itself has been infected. So anyway, so this is a big deal. Even though it's a little farther down there on the top ten, it's still in the top ten, which means it's a big deal. And something that we need to be looking at to keep our applications secure in the world today. All right, so with that, let me say thanks for hanging in there and watching this video with me today. And I look forward to seeing you on the next one.
