[0:00] Hello everybody, good morning, good afternoon, good evening depending on where you are in the world. I’m Katie Teitler-Santullo, and I’m here with Boaz Barzel from OX Security to talk to you about OSC&R: who is OSC&R, what is OSC&R, and then we’re going to look at some software supply chain exposures. A reminder...
[0:00] Hello everybody, good morning, good afternoon, good evening depending on where you are in the world. I’m Katie Teitler-Santullo, and I’m here with Boaz Barzel from OX Security to talk to you about OSC&R: who is OSC&R, what is OSC&R, and then we’re going to look at some software supply chain exposures. A reminder that this is being recorded, so a recording will be available on demand to review and share with colleagues. If you have questions, drop them in the chat and we’ll get to them, or answer afterward. I’m Katie, here in Massachusetts, and we have Boaz, who is in Israel.
[1:01] Hey Katie, it’s good to be here with you, and I really hope we’ll have a great conversation around OSC&R.
[1:20] We better. So let’s jump in. Quick agenda: we’re going to talk about software supply chain security and what’s missing, look at some research and data, and talk about OSC&R. To be clear, OSC&R is an open and free resource for everybody in the community; it is not a product that OX sells. It’s there and available to help the collective community advance their software supply chain security and application security. We’ll walk through it and show you how OSC&R can be your best friend and help you be your software supply chain security savior in your organization.
[2:30] Some numbers on the screen. We don’t want to be fearmongers, but our research team at OX did an extensive analysis, looking at over 100 million alerts over a nine-month period. Two of the most alarming things they found: 95% of organizations in the data set had at least one high, critical, or “apocalyptic” risk within their software supply chain, and the average organization didn’t have just one, they had nine of these high, critical, or apocalyptic risks. That’s a problem, because when we have so many exposures, we have to figure out what to do, how to prioritize, and how to remediate; it’s like having nine unlocked doors at the Federal Reserve, just waiting for somebody to take advantage. And on top of that, one in five applications, 20%, have one of these risks during runtime, which is problematic because runtime behavior is less reliable and there’s a huge long-tail effect if software is running in the wild and a vulnerability gets exploited. Boaz, what does this mean, why should people care about the software supply chain?
[4:23] Great question. Eventually we’re all developing software; every company today develops software, whether you’re a shoe manufacturer or building cars. As we develop more and more software, the increased reliance on software and digital transformation makes it harder to understand what we have built in and what we have exposed outside, and we’re adding more and more third-party parts, especially open source. It’s very easy to say “I want to develop a feature,” but it’s actually easier to just pull in a package, and another, and a third, or copy code from different sources, and have that running without understanding what’s in the code or how my software is exposing me. So I’m building more and more applications and expanding my business, and these unknowns create real risk: financial loss, brand damage, regulatory and reputation damage, disruption to operations. Imagine you’re playing a game, and the server goes to maintenance again, or there are too many issues, or your credentials or credit-card information were stolen; you’re not going to keep paying that company, and they lose a lot of trust. The software supply chain attack landscape is increasing, with more sophisticated attacks, and we want to maintain that brand and trust, which is why we should care about and invest in software supply chain security. Going in that direction, Katie, I’d like to talk about what’s missing, what we’ve learned in recent years about software supply chain security.
[7:39] It’s a complicated problem. There’s such a long-tail effect with software, because more companies are developing custom software but, for efficiency and innovation, using more and more open-source code. I’ve read that in a lot of applications, up to 90% of the code base is from open source.
[8:22] Yes, I can attest to that; I have developer friends who prefer to copy-paste.
[8:27] Right, the name says it all, “code base,” why reinvent the wheel? In a lot of cases that code base is great, but you get these transitive vulnerabilities and transitive risks, and the same can happen with cloud. When developers move at the speed of lightning to get software into the business, they rely on open-source code and elements that don’t necessarily get patched, which means more and more vulnerabilities from stage one, the design, all the way through deployment and distribution. Companies don’t have visibility, the security team is trying to catch up, developers move fast, and the tooling isn’t covering the whole supply chain equally. With siloed tools, vulnerabilities aren’t always surfaced early enough in the development cycle. So when developers fix things, their goal is to reduce the number of alerts and fix the highest-priority vulnerabilities, which seems simple but isn’t, because they don’t have the visibility, the correct tooling, or the time. And attackers understand all of these problems; they have a mindset, behaviors, tactics, techniques, and procedures, while developers are thinking “how do I fix this vulnerability” without the right tools, so attackers get ahead.
[11:07] I agree. What’s the best way to understand software supply chain vulnerabilities? You have to look at the attack kill chain and the different stages, but also at all the various things that go into software development. At OX Security we call this PBOM, or pipeline bill of materials. Many of you are familiar with SBOM, software bill of materials, a great tool to understand what’s in a piece of software. But PBOM covers everything from the development and build environment to the deployment and distribution of applications, not just the code: the environment, the access, the sharing. Your developer posted a problem on GitHub and GitHub keys were leaked; it’s everything that goes into building and deploying software. Our PBOM includes SBOM, API bill of materials, and SaaS bill of materials, so it’s more robust. Even though that creates more acronyms, it’s important to think holistically, because the reliance on open-source libraries, clouds, and containers, and the complexity of all the stages, make the software supply chain a lucrative target for attackers. Over the nine-month research project, you can see vulnerabilities across all the stages of the kill chain, and we have to understand that so developers can prioritize and AppSec teams understand where they need to step in.
[14:08] OSC&R is a great way to understand the software supply chain, because it maps these different stages to attacker TTPs, from reconnaissance all the way through exfiltration, and looks at business impacts. Boaz, can you go into this data and what it means?
[14:46] Yes. Let me start by explaining OSC&R. It’s the Open Software Supply Chain Attack Reference. Those of us familiar with the MITRE ATT&CK matrix have been using it, going back to the Lockheed Martin cyber kill chain and then MITRE ATT&CK, to understand how attackers operate. MITRE ATT&CK covers networks, cloud, endpoints, and mobile, but when we researched the software supply chain, we understood that a framework inspired by MITRE would help us understand how attackers operate in the software supply chain, defend ourselves better, and become familiar with specific points. It creates a common language: when I refer to a command-injection attack and talk to a different security team or someone on cloud security, I can connect the code vulnerability or risk into an actionable insight my cloud security team can take to mitigate it until the code issue is resolved. It also gives a great point of reference for understanding how much of the software supply chain we’ve covered, which areas are more vulnerable, and how to build a strategy through different mitigation techniques. And, as you said Katie, it lets you prioritize not just based on “this CVE is critical, I need to fix it,” but on how attackers operate in your environment, so I can focus on the areas, like initial access or execution, with the most issues. So OSC&R is a great way to build a common language, create collaboration, provide evidence through the attacker’s point of view, and a point of reference to build a stronger AppSec program and mature it. With OX, we’re able to map all your security issues across the entire pipeline into those tactics and techniques and immediately expose the areas attackers will target, so you can get ahead of attackers before they take advantage.
[18:58] It’s pretty robust. Everybody on this webinar has at least seen the MITRE ATT&CK, and this is also pretty extensive. Can you explain who created this, their background, and why they started with this?
[19:20] OSC&R was created by different leaders from the industry, including Check Point, GitLab, Microsoft, and Fico, as well as OX’s research team and founders, along with OWASP. As they tried to understand the software supply chain, they noticed a lot of gaps in understanding how attackers operate, and if we want to develop better security solutions, we have to understand how attackers operate. So they came together, and we see a lot more contribution to OSC&R. Just as MITRE ATT&CK is deployed in many security solutions as a way for organizations to build a strategic program to mature their security, the same is true for OSC&R. It’s a fantastic way to understand software supply chain security in its basics, and then to understand the different tactics and techniques attackers use, so as I build my AppSec program I can find the areas to focus on. OSC&R was built after analyzing a few hundred attacks, more than 300 different types, and companies using it today use it to further understand software supply chain security for their own purposes.
[21:24] Before we move on, I want to point out, a little self-serving maybe, that OSC&R is the first and only current framework of its kind. We have tons of frameworks in security, but most are focused on more generalized security; this is the only one focused on the software supply chain, and the only one built by both builders and users of software in a collaborative way. Groups like OWASP helped contribute to this, which is important because everybody who cares about applications knows who OWASP is and what their mission is. Again, it’s a free, open resource. Going back to the data: now that you’ve seen the matrix, what does “36% of applications with vulnerabilities in initial access” mean? Of the data set, over 100 million alerts and tens of thousands of code repositories and organizations, 36% of the applications examined have vulnerabilities in the initial access stage, meaning poor authentication, stolen credentials, leaked or reused credentials, privileged access that’s available. Access is a problem generally in cyber security, but in software security, initial access means an attacker has the whole pipeline. As you go through the stages, execution (dropping back doors in code so they can drop malicious code), maintaining persistence (creating persistent authentication tokens), elevating privileges, evading defenses, we have a lot of issues. The distribution isn’t centered on one phase: initial access at about 36%, execution and persistence at about 32%, then lateral movement and collection. This matters because once attackers know where the vulnerabilities are, they can hone in on the weak spots; like a tennis player who knows the opponent has a weak backhand and hits there as much as possible.
[25:07] Katie, maybe we should talk about the mapping in the report and what we can draw from it. We see a lot around initial access, execution, collection, and lateral movement, so that’s where we’re seeing most of our vulnerabilities. When I see this, I immediately think we should invest in some of these five, and when thinking about defenses I’d want to start with initial access and execution first, because if I can prevent attackers from ever getting into the environment, that would be best. What’s your take on the results?
[26:05] Obviously, if we can shift left and prevent attackers from getting in, that’s the best thing. Initial access was where most vulnerabilities were exhibited, followed closely by execution and persistence, then lateral movement and collection. If you relate where the vulnerabilities are to where the high-severity vulnerabilities are, the shape of the graph is fairly similar, so we still have these five or six areas where there’s more risk. But it doesn’t mean you should only invest in or put processes in place for these areas, because if you look at OSC&R and the report, cross-technique vulnerabilities are very highly prevalent. The researchers found that the more stages an attacker could combine, the greater the damage overall, so you’re amplifying the effects when an attacker can hit an organization’s pipeline software from build all the way through deployment and distribution. You’ve also got age-old issues: 31% of apps evaluated have back doors in code, a 25-year-old issue we’ve known about forever, and it’s not easy to fix.
[28:30] So what does OSC&R mean for ADR, application detection and response? It helps companies understand the mindset, motivations, tactics, and techniques of attackers, unify vulnerability insights, and understand where the biggest problems and risks are. It’s important to point out, and I’ll say this in a public forum and hope our boss doesn’t get mad, Boaz, if you contact a vendor that says “we can do everything, it’s a silver bullet, set it and forget it,” run away as fast as you can. You need a vendor that understands the attack life cycle and software development and gives you flexibility in your tool set to execute the processes that shed light on your areas of exposure.
[30:03] I completely agree, and beyond flexibility it’s also about evidence. Don’t just set it and forget it; tell me what you’re seeing, why it’s critical, show me the attacker’s tactics and techniques, show me the evidence in my code, how it behaves, whether it’s deployed. I want all the evidence, so even if I automate the decision-making or ticketing, I’m building trust between teams and my results are accurate. And connecting back to OSC&R, show me how attackers are going to attack me, because for my organization it’s one thing and for yours it’s another.
[31:22] What makes a good ADR or ASPM tool, especially around prioritization and alert triage? We know from the OSC&R report that companies are managing 129 applications and almost 120,000 alerts, which seems unmanageable.
[32:20] Great question. In the beginning the focus was on scanning and getting results, because it was like a black box, and now it pops out a lot of alerts and nice data, but companies realized they have no idea what to do with all these alerts, just a lot of red dots flying around. So from a visibility perspective, first show me everything together; paralleling IT, it’s like building a SIEM, where most ASPM started, which is a nice first step but not the final step. Even seeing 120,000 vulnerabilities isn’t helpful, and if I want to operationalize and get developers fixing problems, I need to decide which problems. That’s where ADR comes in: before ADR, understanding the context of the environment and what’s really critical for me, but then using OSC&R you can implement an additional layer of understanding. Customers aren’t just looking at what we say is critical in our prioritization, they’re looking at what attackers will be doing and where to focus, like initial access and execution, and it considerably reduces the noise, showing me the five or six items I need to fix right now. If I had six items, I’d be happy; you have 20 or 30 in your backlog. This is really where I see security teams understanding the areas, working better with developers, doing their job, having an impact on security, showing they’ve reduced risk and increased customer trust. As part of their security strategy, from a build and design perspective, I’d like to include a framework that helps me understand the attacker perspective of what I’m building, and plan my defenses accordingly, instead of at the end of the process developers coming to me to release something and me being surprised. If you include it really early, as they start writing the code, you immediately see the areas to be alerted about or focused on.
[37:24] Oscar for ADR makes a huge amount of sense; it’s a framework focused specifically on applications and helps shine the light on where to go. I think of it like the difference between a paper map and a modern GPS. With a paper map, you have to plan, are there one-way streets, construction, landmarks, and I got lost a lot. GPS tells you “go left,” it shouts at you, avoid this problem on your right. That’s what OSC&R does for ADR: it gives a detection and response capability that’s a lot clearer, and getting everybody on the same page is super important, because right now we don’t have a common language; we have a development language and a security language, and sometimes they meet and there are fireworks. We want common language, common understanding, and collaboration between developers and security.
[39:46] I love the analogy. The difference between the GPS and the digital map versus the one that got rained on or crumpled in the passenger seat; it just wasn’t sustainable. And with the digital one you don’t have to stop, you just keep going.
[41:24] Let’s move on to next steps. As we mentioned, OSC&R is a free and open resource framework; we want you to use it and be part of the community, at pbom.dev. Don’t just download it, use it, because it’s going to help your organization build its strategy and defenses. It’s an organized, structured way to look at how your organization develops and deploys software; it uncovers the most important risks and shows you how to prioritize them by their prevalence in the attacker life cycle. You end up with an improved software supply chain security program focused on the entirety of the application-development life cycle, and it gives your AppSec, development, and product security teams a common understanding and a good way to detect threats early, because the earlier in the kill chain you find them, the faster and better the remediation, and the more reduced your attack surface. It gives teams a systematic way to look at all stages and the most concerning areas and put your defenses there. Looking at how attackers think and act, security and development teams can practice their defenses and prioritize the highest-severity issues, because we don’t want these issues to become incidents, incidents to become declared breaches, and breaches to cause operational disruption, compliance issues, and legal fines. And OSC&R brings community collaboration and continuous improvement, which is why we want people to get involved.
[45:03] What’s the threat-related thing OSC&R serves as the foundation for? It’s the foundation for very successful threat modeling. As you think about your security program, your applications, and how the business operates, you want to understand the scope, where to focus, and where you’re vulnerable. To use another analogy, OSC&R helps you predict where the ball is going to land, so you can put yourself in that spot and prevent the ball from ever getting into your own goal. It lets you model your organization based on threats affecting your own specific applications, which lets you create a genuinely effective program that hones in on actual risks you can plan for before the code is even developed. It also helps you set the right amount of time for developers, because you know there will be security issues and they’ll fix them, so you build that into every cycle. Companies using OSC&R today see that security actually complements development and lets them get to market faster: instead of stopping them just before release, they get the right information at the right time. I had a conversation with a customer today that saves them days on every release; they release once a week, and now they release on time with more features per release.
[47:54] Absolutely, and that threat model is super important because it’s individual to each organization. To wrap up: join the OSC&R community at pbom.dev. Look at OSC&R and see how you can apply it to improve software supply chain security, detect threats earlier, reduce your attack surface, and get a faster mean time to response, all underpinned by that threat-modeling individuality. This is not a plug-and-play tool, it’s a tool to use that keeps you involved in the process, working with development teams and fellow security teams to make sure this is a living, breathing thing. Do we have any questions?
[49:02] I think it’s really clear, we did a good job here. Everything is understandable, but I just want to reinforce joining the community: as OSC&R gets more collaboration, and we’re seeing a lot of people contribute, it will allow more organizations to better understand software supply chain and meet those issues head-on, which benefits the entire community and market. Thank you very much, and thank you for sending your thanks through the chat.
[50:03] Thank you everybody, we’re going to wrap up for today. If you have further questions, please let us know. Boaz, thanks for joining me for a fun conversation.
[50:15] Thank you Katie, it was amazing. Thank you everybody on the line, and we’ll see you on the next one. Have a great one.
