[0:14] Welcome back, and thank you for continuing with us as we cover Black Hat 2024. I’m Mandy Logan with Security Weekly and Cyber Risk Alliance, and here with me is Boaz Barzel, the technical evangelist and director of enablement at OX Security. [0:33] Thank you, you’re very welcome. Today we want to focus on...
[0:14] Welcome back, and thank you for continuing with us as we cover Black Hat 2024. I’m Mandy Logan with Security Weekly and Cyber Risk Alliance, and here with me is Boaz Barzel, the technical evangelist and director of enablement at OX Security.
[0:33] Thank you, you’re very welcome. Today we want to focus on AppSec, which is what OX Security has gotten all their fingers into and is really interested in helping with, and it’s becoming increasingly important. I’m curious first about navigating the path to maturity for AppSec. Can you give a quick summary of what the state was and where it’s going on maturity for AppSec in general?
[1:05] It’s a good question. From a maturity standpoint, what we were seeing in the past was a lot more focus on discovery and bringing tools to help us discover security issues and vulnerabilities within the code. If we go further back, application security was mostly around applications that are actually running, with little aspect of code analysis. But today, with all the development increase and agile methodologies, companies are shifting their gaze more to the code, to what’s coming into the application, and now that developers are releasing code on a weekly or even daily basis, it becomes very challenging just to have those vulnerabilities listed for you. So the next area of maturity for most companies is generating context: not just the ability to create coverage, but the visibility and context to help them prioritize in an automated way, not spending days or weeks manually going through vulnerabilities trying to decide which are critical, and how many hours I can get from development to remediate them. This is the next level, where a security platform provides that prioritization and consolidation, giving you the critical security issues that, once developers fix them, fix the root cause and behind the scenes resolve a lot more vulnerabilities. That’s the next level of evolution for most companies, and companies that already have that are building automated response protocols, which you can also do with OX.
[3:13] So are you telling me that the advances in maturity are part of a move toward secure by design?
[3:24] That’s a good framework to use, and there are a few more. Eventually, yes, we want a framework that helps us understand everything from the design phases through where developers are writing the code and choosing what open source to use, and maybe writing modules that help sanitize input, so if there’s a vulnerability we’re mitigating it even before building the application. The problem is that today applications are built from a lot of services, micro pieces building a whole application, in contrast to how it was built previously, so it’s different and the complexity means that just using a framework is good, but companies already have so many security issues and vulnerabilities, their backlog is huge, and it’s a risk they already have right now. So using a framework like secure by design, SLSA, or NIST will help in the long run, but the focus should be on understanding their current posture and the risks and vulnerabilities they need to fix. One of those frameworks you can use is OSC&R. OSC&R takes maturity to the next level, with application detection and response converging into application security testing, software supply chain security, and ASPM. When you put everything together, you finally get a real picture of how exposed you are, not just the critical areas to fix but how attackers are looking at your vulnerabilities and what they can do. Then you can start handling your current security posture, eliminate manual AppSec through, for example, the no-code workflows we provide, and have time to look at strategic, long-term programs, implementing those frameworks to reduce future risk.
[5:50] Which is what we all want. We want the Minority Report ability to predict and handle it ahead of time.
[5:57] Exactly, it’s a good reference.
[5:59] Going back to OSC&R, I want to confirm that is the Open Software Supply Chain Attack Reference.
[6:08] Exactly right.
[6:08] In your experience with OX so far, when you look at the industry, what percentage of organizations have a dedicated AppSec person or team, or do they not need it? How many organizations really don’t have to deal with AppSec?
[6:27] I don’t think there’s an organization, maybe 5%, that don’t develop software. Software is what everybody’s doing. Even big manufacturers, shoe companies, car companies, they’re all software companies eventually, and a lot of what they do relies on that software, even their internal processes. So almost every company in the world develops software, and because they develop software, they’re turning their gaze to application security. We’re seeing more companies having that position, and complementary positions: product security coming from the development side, and DevOps and DevSecOps integrating security into the different areas of the pipeline. The market is growing exponentially; all the reports indicate it’s phenomenal. Once network security, endpoint, and cloud became a commodity, they’re shifting their gaze to the code, and they want to fix something before it gets deployed, because if it’s deployed they’re already at risk. So I would say more than 90% of companies have an AppSec position in the organization, and more than 50% treat it as more than a budget line, it’s part of their risk; application security is one of the top-five risk elements the board is looking at.
[8:18] What are some of the biggest challenges facing application security?
[8:22] The biggest challenge today is the manual AppSec practices: you have to do a lot of the analysis and response manually. Discovery we’ve probably taken care of, but then the outputs, the visibility, understanding and analyzing vulnerabilities, who’s the owner, who to approach, how to fix it, is it critical for me, what’s the effect on the business and the environment, collecting that context, all of it has to be done manually. If I don’t need to do it manually, I can skip to the next stage, which is response, and that’s where companies can leapfrog years ahead. That wasn’t the case in IT security, where we had to go through antiviruses and firewalls, then IPS, all collected into a SIEM, then EDR and XDR. One special thing about OX is we understood it from day one and built the next generation, so we’re leapfrogging into XDR-style response really quickly without going through all the stages. So understanding the context of the environment, your business, and the attack surface, connecting all the dots, and providing the few security issues you need to fix at any given time, that’s the main area of focus and a challenge for a lot of companies.
[10:13] I’m curious about your take for the C-suite, the executives who aren’t in the daily grind of “these application security processes are manually done right now.” Is it fair to say that maturing their application security practices is dependent upon eliminating the manual processes, or what other items does OX zero in on as allowing maturity to come in?
[10:50] The first item is to understand how much time it takes to fix an issue, starting with how much time we spend analyzing vulnerabilities when we discover them, and trying to measure the friction between the security and development teams, which is difficult. One idea I liked, which got a financial company huge advancements in remediation, is that they started to gamify the development teams. That gamification provided scores for the different engineering teams, and eventually the managers of those teams got, as part of their KPIs that they get bonuses on, being at a B or an A score. They were able to gain more traction from development to fix security issues; he told me they were working weekends just to get to an A position and started bragging about it. So that’s one idea you can do as a CISO or C-suite to motivate people to reduce your security risk.
[12:26] I want to go back to that, because many times application security is handled differently than other security programs by the mere fact that the security is thrown back on the developers. Can you speak on that? It’s a very different mindset, throwing the security requirements on the developers, which isn’t necessarily what they thought they were there to do.
[12:59] This is a great point, and one of the major differences between application security and the rest of the security spaces. There, control and remediation are in the hands of the security team; here, remediation eventually is on the development team. Security people can’t remediate; they see the vulnerabilities, prioritize them, and send them to developers to remediate. But eventually a developer looks at code and says, “okay, this code works, I need to finish my next task, there’s another task afterwards, we promised a customer we’d release this software, I don’t have time to fix security vulnerabilities.” That’s challenging, and it’s something that separates application security from the other security markets and requires a different approach, a continuous approach. I can’t come to a developer with a vulnerability I spent days or weeks to analyze, only for the developer to say “we already fixed that” or “we’re not using that library anymore.” It has to be continuous and real-time. A lot of OX’s customers are enjoying that today, getting the information in real time as developers add new components to the code; they understand the criticality immediately and can fix it in the development phases, not later when we’re about to release and I have to decide whether to stall the release or release with the risk and fix it next release.
[14:48] In summary, what information can you provide to our audience about how OX really helps the application security posture of a company, since we discussed that 90 to 95% of companies, no matter the industry, are also in application security? What does OX do?
[15:08] The first thing OX helps to do is eliminate manual AppSec practices, providing coverage on the entire pipeline in a single platform: collect the information, correlate it, consolidate it, and understand the context of how the business and development operate and the attack landscape. Use OSC&R and application detection and response, connect different tools, not just OX’s native tools, and the first thing it gives you is complete visibility into the actual risk, the critical aspects, and guided remediation, what to do next. So when I build a no-code workflow, I can start responding to security issues without spending a lot of time analyzing them, opening tickets, and chasing developers. I’m also recommending that once organizations implement OX, they start thinking strategically, because the daily tasks are covered and the evidence is there, so they don’t have to continuously prove to development why it’s important; we show reachability graphs, exploitability, and all of that. The next part is thinking about the next application I’m going to develop, what the security elements are, plugging it into OX, and through development we start analyzing everything, so even before release you understand the expected criticality of specific elements. We also deprioritize a lot of elements, creating a cleaner view and reducing noise, which eventually lets the security team focus on strategic aspects, building frameworks that create a better ROI for the business. What we’re seeing with companies we work with is that every time you integrate security into the pipeline, there’s a reduction in the velocity of development; with OX that reduction is almost non-existent, and development growth is actually faster than expected. So we’re seeing OX as a business catalyst, helping businesses expedite their applications, reduce risk, and become more competitive in the market, not just on the initial release but on subsequent releases.
[17:52] Exactly. It’s continuous over time, and when you’re releasing on a daily basis, you want to know exactly what you’re releasing and the risk it creates, and if something needs to be held, you want to know as soon as possible, not at the end of the process or after release. For example, we’re able to correlate a lot of the container issues to code issues, so we immediately know when a container is built; we’ll see it in code and in the container, and automatically link it to the relevant person, a ticket opens, they fix it, build a new container, and that’s it. It’s really amazing the path we can take.
[18:36] It sounds like a lot of streamlining. Beautiful. Boaz, thank you so much for joining us today.
[18:41] Thank you, it’s my pleasure.
[18:43] To continue with us today, you’ll be able to see our closing for Black Hat, and to find out more about OX Security please visit securityweekly.com/oxbh. If you can’t stick around for the rest of the live stream, or if you’re catching this afterwards, please head over to securityweekly.com/blackhat to find all of the Black Hat coverage by Cyber Risk Alliance.
