Okay. Hello? Hello here. Straight out of Singapore. I don't know if you can see it, but one of you will see it. I'm right here at blackhead Asia. It's a security conference. So let's see. I hope select was a stuff is not too big so that I can, yeah. Do all this without any technical issues I have now the biggest challenge starting the PowerPoint slide, but I will do it right now. So I dunno if any, one of you can ask questions. I think it could be by voice. So if you have any questions, feel free to, to do so. Okay. So finally my screen should be online. I hope you can see it.
I have no feedback, that's it. So I trust that you will see my slides now, so let's start.
Okay. So by the way, my name is, and I'm working here for JRO in the field of cybersecurity INGOs, and we want to talk a little bit about supply chain security and solo hack and all this stuff. And what does it mean a little bit from the technical perspective?
So what, what developers are doing, but mostly it's interesting to see it from the management point as well, or from the architectural point of view, because all this stuff is more or less. Yeah. Going hand in hand. So what happened in the past? What was the reaction from the us government? The executive order of cyber security and how you can prepare in the current project or your next project. So I want to go a little bit through the point. What are the low hanging fruits where should start or where you can start and then, yeah, let's see.
So, as I mentioned, my name is van I'm from Germany, and I'm mostly hanging around in the woods if I don't have to work. So if you want to see a little bit more of my stuff, you can check out my YouTube channel. I have a lot of this cybersecurity or devs related videos out in the woods, definitely in different theme as a regular one. But now we want to go here is a topic what we have. So what happened solo sec, I assume the, most of you heard about this already. I'm not going into all the details, but there are a few things that coming more and more up to us in different yeah.
Kinds of industries. I'm looking at this for software development, but we have this challenge more and more. So it means that we have more and more attacks that are not against the final target.
So it means with the solar hack, what, what, what happened? Just a short overview. So there was this company that is building software software that is able to manage networks. So mostly customers that are using the software.
They are big companies because they have to manage not only one server, they have to manage tens, hundreds, maybe thousands of servers and the infrastructure they want to monitor and administrate all this stuff. And this company that is building the SolarWinds that is building this orient platform with a product name and they have in-house development. And inside this development areas, they have C I C D pipeline, very coms staff, ops pipeline.
So they have a lot of stuff automated to, to build software and the group or individual, whoever it was that hacked this network from Sullivans, they, they not compromised the data. They're not stolen data, they're not destroyed something.
What they have done is they search for the CI pipelines. So this pipelines that's responsible for converting code to Bies, to building all this stuff and manipulated the build infras structure or the build configuration means the company itself was not aware of this change.
And with every new build, with every new release say they created, there was a, yeah, they created this binary, but a compromised version of this bar. And now what, what happened then is just after they updated or they presented this update and all customers, or a lot of customers had this automatic updates. They grabbed this B from the vendor, installed it. And I think in a few days they affected 12,000, 50,000 customers. It means not only single service, it means really different networks. So what we can see is that the tech group really uses platform to, to have a multiplier.
So really to scale in a huge way. And this is more and more coming to us in, in all kinds of software development, all software supply chain chains. So what does it mean for, for all the people that are just consuming software that's okay. You have to make sure that you're not consuming compromised stuff on the other side, for all that are producing software. We have now to, to directing, we have to protect ourselves against it's one, how to make sure that I'm not consuming compromise software and how to make sure that I'm not distributing software.
Because if, if you're pushing all this stuff to your customers, you can imagine what this mean to you and your business. So we, we are now more or less with software development in the middle of consuming, distributing this stuff.
And yeah, so this leading to the right now, little bit more use term supply chain security for the whole supply chain.
And there are a few key factors that showing during the last few months, or, or less since one and a half year, now that we have more and more critical elements or elements that are more dominant in this supply chain security attacks.
So, and one thing is, for example, this compromising geopolitics, what does it mean half year ago or a year ago? It was more or less, okay, you have this global things that happening and they try to use this to influence you and, and all this stuff.
But now, since we have this challenge with the actual ongoing activities and the, we have the challenge that if, if you are in the supply chain of, of a bigger company and you're providing services that you're not attacked by individual groups or individual persons, it could be that you're now attacked by governments. And this is a huge thing because they, they have more resources instead of a single group of two or five high skilled people.
So they have really departments have huge infrastructure what they can do.
And yeah, so we, we see during a few weeks that this attack against this small medium business house companies are really not only done by the regular hacking groups we are aware of, but now we have this attacks from, from governments, cyber, they adopt hustle and diversity.
So what, what we see during the last few years is that from individual groups or individual person say they're more or less building groups, even if they're loosely, coupled very prominent example is an they it's, it's a bunch of highly skilled and well high motivated people that have not always financial things in mind, if they're doing something we have more and more attacks that are not only try to earn money, they try to, yeah, they are on a mission on a political mission on a religion mission, whatever.
So we, we have more, more threats in this thing.
And this is immediately causing to some other challenges in software, supply chain, things it's expanding more and more usage for some of this ware. The early stage ware was just used to encrypt systems and then you could pay and Susu was more or less really. So it was more or less free again, if, if you trust that's gone, but you, you were able to get your data back.
And I saw a lot of companies during this last one or two years, that calculated in a way, okay, the, the value of, of this supply chain part is maybe 2 million and I'm not investing half a million or a hundred thousand or whatever, because it's very unlikely that it's happening. And if it is happening, we are strong enough so that we can just pay what, what they want is 2 million.
And then we are getting rid of this stuff. This is not working anymore.
So this random stuff is more, more aggressively, really used to destroy things, not only to, to get money, but the other thing that is more or less raising is here that the big companies inside the supply chains, they, they have the manpower, they have the infrastructure, they have the knowledge and the money to make themselves very, let's say secure. So their hardening their own systems. But this means that the whole pressure that was mostly the old days against this big companies is now against the small companies that are bringing stuff to this big company.
So even a 20 hat company in the middle of nowhere in Germany is now attacked by yeah, by this groups. And this was not three years, four years ago, this was definitely not the case. So as much this big companies are Harding.
Their system as higher will be the pressure for all the small companies around this big company, because they, they are now the, the new target as accelerator or as multiplicator. And what's coming. One more is that most people are talking about software vulnerabilities, but we have vulnerabilities in hardwares itself.
So how to deal with compromised hardwares could be hardware, mistakes like Spector or other things that, that you can misuse some architectures in processors and other hardware, but it could be compromised hardware itself. So we saw that some chips that were produced in some countries where manipulated against original plan with, with elements that, that allow to get removed access to this stuff. So there is a, there's a huge broad thing. So supply chain security is, is a huge topic way too much as I could handle here in this 20 minutes.
But what we can say is we can focus this now to software software world.
So what, what is going on during the supply chain, if you're producing software, and there's a very nice project that is an open source project from the Lenox foundation, it's in documentation project, it's called S a SSA. And this project is more or less based on the knowledge of a bunch of individuals.
It's, it's not led by a company it's, it's really individuals and companies are supporting it, but there individuals describing, or try to document the way how you can identify on what level you are with your own defense and what would be the next logical step to hard new system. So this is a very, very good resource. So if you want to read a little bit more, this it's a very young project, but it's a very good project. So have a look there. And I took one of these pictures, exactly. This one here, just to show what are the common takes against the software supply chain?
We, we have the difference between source threats, built threats and dependency threats. And that means you can attack the source grid itself before it's will be built and transfer to Bunco and use somehow how you can attach a whole build chain. So the way from salt code to binary and distribution, and we, this dependency thread.
So it's, it's more on this direction, not only vulnerabilities, but Malian packages for, and packages and all that stuff. So, and so what, what, what are the typical states we, we should be aware of is mostly if the developer is writing code and providing this piece of code, the first step is that you should be aware that not only one is allowed to, to commit code to a dedicated system, but you have some kind of review. It could be in the same company, it could be decentralized, whatever technique you're using, but having this code review or this in general.
So it means most are reducing or things that code reviews just on the search code you're writing. But mostly if, if you're in this direction of infrastructures code, so declaring infrastructure or configurations in the system that this will be done by as well. So you don't have this administrator that will have the right to change configuration, having a mindset, a lot of attacks are coming from inside the company. So you have always this feedback loops as a revenue.
If, if your storing source code somewhere, for sure this system can be compromised. It's here compromising source control system. So you have to hard, you have to think about, do I have enough power and, and knowledge insights, or that I can hard my system that I'm using internally really by myself, I'm I'm able to do this. Yes or no. And quite often, I see that that a lot of people think, yeah, yeah, we can.
But an external audit is not bad because mostly it's, it's not the case because the quality of this it takes is increasing dramatically.
If you have this quote, repository could be for the configurations of salt quote of your product or whatever you have, you have this gateway from the source code repository to this build machine, the CI pipeline. And here you have a build threat, but it's based on source code. It's more or less this modified code after source control. So you have this bypassing. So it's built, infrastructure's grabbing the code from the repository and you can slightly change the build configurations that after grabbing the sales code from a second place, additional source code will load it.
And you have an overlay. So your overwriting classes, or you are adding additional source code, and without even compromising really the binary itself, you're compromising code in, in the way that you're modifying it.
After the source control again here, what, what you have with compromise build platform, that's just the next one is how to harm this one, how to do this. And from this, you are just building this binary building. This binary means the machine is doing all this stuff. So compiling and linking and whatever is necessary, producing what you want to let's go to the production.
And there, there a gateway from, from this build entity to some packaging or repository type from which the production will be feed. So where, where there's stuff is stored.
And he, again, you have two things you can compromise the way itself. So someone is bypassing build configuration. So he's just building this battery on his laptop and going to this package management system saying, okay, I'm, I'm a build infrastructure. Please accept my package. Or you can just compromise the package manager itself.
So again, he infrastructure, you have to harden have to see what, what you want to do. And from this, it's going more or less to the consumer.
So what, what I not picked here is all this stuff with dependencies and why? So as you can see, you have a lot of infrastructure part, and this is more or less always the same. You have to identify if you're able to protect it. And if yes, what you should do, there's one thing. Then you have a few of this manual processes like codes and all this, but in very good approach, here is zero trust environment that even the communication in-house, or even if it is insides, own private managed cloud in your company, so that your have is zero trust environment. That's the components.
They are not trusting each other, but you have the verification mechanism so that this communication internally is secured as well.
But we have a bunch of dependencies, and this is all the stuff that is coming from outside. And this means how to deal with it. So everything you're not building by yourself, what you are consuming. And this is where the most techs are. So taking a big infrastructure is quite complex.
A tech rector is, is not easy, and it's not so easy to reproduce, but if you're able to find something to compromise boundaries that are consumed somewhere, then you don't have to care about infrastructure security and all this to, to get inside the system. You just let them consume something. But what are the basics in, in terms of cybersecurity? So we have a few main strategies you could focus on. One is for example, or the, the first one that mostly mentioned is, is SIS static, application security testing.
It means whatever components you have, you start scanning all the binary, the configuration, and all this stuff, and checking the static, semantics of the stuff to identify if you have vulnerabilities in what is going on.
And so what I'm missing at this point is that you are not aware of this dynamic context, what the application is doing. So the that's, the dynamic application security testing is more, less focusing on looking from outside at this application or this infrastructure part, and try to hack it mostly based on the most common vulnerabilities.
So SQL injection and whatever you, you want to use here. As, as the most common one, they are list of most common vulnerability anyway. So you can use this as, as reference read, but attacking from outside, you don't need the knowledge about technology.
You, you try to break in, but on the other side with this, you're not able to scan really a hundred percent of all the components you're using to build this infrastructure. So it's it trade off and you have to, you don't have to decide, but it's a different approach, a static one and the dynamic one.
And then the people says, okay, if, if this different things are hacking from alter and scanning from internal, I can combine it. It's called interactive application security testing. Let's say it's something like a security debugging of the system.
So your house system, you have access to all components. You can attack the system at the same time, you're monitoring internally. You can stop, you can change their tech vector and all that stuff. But for this, you need very high trained people. So it's mostly not so common that you have a really educated person in house for this. And then there's some completely different thing. Cause everything here is before you are going to production and RA runtime, application security testing or protection or testing is the ongoing thing. So on production, what is going on if you have an ongoing attack.
So rasp is really just to identify, there is an ongoing attack.
There are several providers with machine learning. They try to find out if this interaction patterns exactly what you are expecting, and then you can shut down or just monitor, alerting all this. If you're checking all this, where, where should you focus on? So rasp is definitely just the last thing you should or more or less, the last thing you should do, because this is just protecting against ongoing stuff, but you're ignoring all the stuff. And security is something like quality.
You, you should do it in, in all steps of your production line. Not only in the last thing, interactive application security testing is mostly used. So you need the right skilled people in house.
So it's, it's mostly an advanced technique. So you should start with Z or dust.
And here, if you're in the production, if you're an software developer software development unit by yourself, you should start with static application security testing because you have control about all the components.
And if this is running, you can go to dynamic application security testing to extend to the dynamic at. So this is more or less just overview.
So having a mind that if you are able to scan all components or have access to your components, you're running, you should start with static scannings because then you really can scan the whole stuff and sometimes component analyze with checking configurations, something, but whatever you're doing, if you have different stacks in your applications, applications, operating system, then maybe a virtualization like DACA and then orchestration like Kubernetes, whatever you have different dimensions. So you have domain specific things and security against domain specific things.
So can I misuse this use case, for example, this is something that is mostly not the case here, where tools are helping. You have to go to the technical ones and you are just adding this every layer more and more of vulnerabilities.
So having a mind, all this dependencies you should scan for, and you have this dependency managers that can scan this. Isn't very easy thing.
So because you have the metadata and the binaries, and with this, we are able to let's say, yeah, going through all technology layers to identify tech vectors against or through the whole text, we have so low hanging fruits compared what you're doing by yourself. And the dependencies you have is mostly the stuff you're doing by yourself is very, very small compared to all the dependencies you have, you should focus on all the external stuff, cause this is most of the bigger thing.
And here have in mind that not focusing on one technology layer, because vulnerabilities are split on different technology layers. And with this, you're able to build different tech vectors in your system. So make sure that you have the fully, the fully understanding of the impact or the impact graph or the whole stack you're using.
So what is the best, what you can do if you are by yourself, software developer is a good test coverage. If you're consuming or working with the software development company together, make sure that you're using a very strong test coverage.
Because with this, you can change dependencies very fast without doing all this manual test. And this is what is very necessary. So if you have vulnerabilities, you must make sure that in new composition of the same components in different versions must be in production as fast as possible. If you want to learn a little bit more about the lifeline of a vulnerability, check out my YouTube channel, I have it in German, have it in English so that you can see there. What's what's going on.
If you're interested in the technical part, check out instead of line coverage for mutation test coverage, there's more or less for the developer part in the audience.
So make sure that you have this very strong test coverage, because this is a first safety build, not only for quality, but for the fight against vulnerabilities itself. So was cyber security, this executive auto cyber security. What does it mean is that the solar tech destroyed so many resources in the use government, that there is a software build of materials.
You, you have to build. It means a full list of ingredients of all components and this over the whole text stack. And this is more or less what you can request if your consumer as well from your providers, because they are more or less yeah. Prepared for this. Now ASBO you have different techniques, sometimes built called different. For example, at J frog and working, we have this term built in for it's a super set of air spam. So from this, you can extract the ABO that you can feed your auditing tool and so on.
So there are several ways to, to get to this information, but make sure that you have some full list of this. Okay.
A few words again, for the CVSs values. I see so often that people are talking about CVSs values and they're just focusing on the base metrics, how critical the theoretical part of this base metric is.
But the main thing here is that we have two different things like as a Al metric and the environmental metric, and make sure that you're adjusting the CVSs values with environmental metrics to your own needs because sometimes a very high risky thing is in your environment, not so risky and reverse. So make sure that you have access to this different metrics inside a CVSs value. If you want to more about this, have a look at my YouTube channel again, and they have a dedicated talk about the CVSs values itself.
So it's, it's not only for the developer. It's, it's good for the management for the strategic, for the architectural view. Cause this is exactly where you can measure the balance between how critical different vulnerabilities and different layers are. Okay. So there are several projects I just want to mention because I'm running out of time. There's one thing for open source software project. It's called Persia. It's a open source project from the Linux foundation where they start with a D package management thing with
Phone you're coming to the end of your time.
So perhaps you could give a quick summary.
Yeah, it's a summary. So what should you do if, if you want to prepare against supply chain security attack, make sure that you have control about all boundaries and don't focus only on your application, make sure that you are getting the information for all infrastructure parts.
So most people are just focusing on the application, but they're forgetting all the environment, the compiler, the build infrastructure, the router, all this stuff, make sure that you're doing everything with the same technique and make sure that the topic security is not only a dedicated part of the company, make sure that in production, in usability everywhere. So the whole part is aware of this. It takes and start dealing with his topics called security is something that's everywhere. Okay. So I'm crashing the time 20 minutes eyes. Definitely a short time.
So sorry for grabbing a few minutes and yeah, if you want to know more, just ping me on Twitter, LinkedIn, whatever's comfortable for you and yeah. Then
Thank you
Very much. Well meetings from Singapore.
Thank you very much, indeed. That was a most comprehensive and complete description of everything that you really need to do to deal with this problem and to make sure you're going to comply with this executive order. So thank you very much indeed for your time in giving this.
