[2:35] I am Katie Tisler-Santullo, and I am here today with two of my colleagues to present to you a unified playbook for operational remediation: aligning people, process, and technology. Before we get started, a reminder that this webinar is being recorded, so you can go back and re-listen or share it with colleagues, and...
[2:35] I am Katie Tisler-Santullo, and I am here today with two of my colleagues to present to you a unified playbook for operational remediation: aligning people, process, and technology. Before we get started, a reminder that this webinar is being recorded, so you can go back and re-listen or share it with colleagues, and if you have questions please type them in the chat. I’m Katie Tisler-Santullo from OX Security, and I’m very excited because today we are joined by Tomer Yanovich from Seemplicity. Together we’re going to walk you through a unified playbook for operational remediation, and then demonstrate how OX and Seemplicity partner, how we’re better together, in solving a major challenge that all of you probably have. Over the next 30 minutes we’ll discuss the all-important PPT: process, people, and technology. You can’t have one without the other two, and you can use them to dramatically improve the way your organization handles AppSec remediation tasks. Then my colleague Aaron Miller will walk you through a live demo of how this all works.
[4:37] Tomer, welcome, please tell everyone a bit about yourself.
[4:45] Thank you for inviting me, happy to be here. For my 20-year career, the first half I was in the telecom industry, and the last 10 years in cybersecurity. I’ve led product teams in cybersecurity at Bionic, which was purchased by CrowdStrike, and now at Seemplicity.
[5:09] Fantastic. And Aaron?
[5:16] Thank you, Katie. Hi everybody, nice to meet you all. I’m a sales engineer here at OX, and I really love the product and I’m excited to show it to you. My background comes from API infrastructure; I used to work at Kong, which is an open-source API gateway, and at a number of startups that do integrations at the API layer. I’m very familiar with the challenges DevSecOps people have, so we’ll show you that later.
[5:47] Great. Tomer, we’re here to talk about vulnerability remediation. There’s a huge challenge: so many companies have misalignment between their tools, people, and process, because a lot of the time in security we put tools before people and process. What ends up happening is we get delays, we get things prioritized that shouldn’t be, and we get a lack of focus because everybody has so much to do. This issue in AppSec and software supply chain security becomes really problematic. One thing that can help is creating a unified playbook: it brings people together by getting everybody on the same page, because we have silos and a lack of visibility. Talk a little about the risks and what people can do to reconnect with their workflows using an operational playbook.
[7:05] We’ve had this problem for a long time and it still hasn’t been solved. It’s not just that the volume of vulnerabilities is going up; the attack surface is expanding. Back in the day we just had on-prem, and now we’re looking at clouds, very dynamic, things spinning up and down. Even worse is the whole application security field, which according to research changes 100 times faster than cloud infrastructure, because the process has changed. We used to deliver software releases every six or three months; now we push code every day, all day. The business isn’t going to slow down and wait for security, business will always win over security, but that means there are a lot of vulnerabilities out there because of the fast pace of development. People have realized it’s not just about technology and not something security teams can do on their own. They used to try to prioritize as best they can, but you can only prioritize so much; at the end of the day you have to remediate. That part was a little neglected, and that’s where the focus is starting to turn, to see how it can become more efficient, and to understand that security depends on the other side of the equation, the people who actually fix those security issues.
[9:06] We really need more collaboration and coordination, because in security we talk about being overwhelmed, and developers are overwhelmed too. The lack of unification and automated processes, and the mistrust, creates a lot of extra work that doesn’t help anybody. Misalignment and inefficiencies are common in teams, and we’re seeing a bunch of issues crop up across organizations. Across the board with AppSec and DevOps teams, remediation without prioritization insights or coherent workflows creates a big part of the problem. But we also have an attack-landscape problem. Can you talk about that, because a lot of people misinterpret what attack landscape means when it comes to software development and remediation?
[10:45] We’re seeing it with our customers, and probably you are too. The number of integrations we have today is 127, and it’s going up every day, because the landscape is so big. Different companies specialize in a subset of the cybersecurity segment, because no single company can cover it all. Vulnerabilities fit not just along the CI/CD pipeline but also in the cloud, where the infrastructure is always changing with dynamic services spinning up and down. There’s never really a time the network is fixed and you can say the security posture is set. It’s always changing, so you have to keep monitoring and increase the frequency. Part of the posture also looks at scan coverage: how much are you really scanning, and what’s the frequency? That’s very important, because if it’s not up to par, you’re working with unreliable or out-of-date data. The attack landscape spans application and cloud, misconfiguration, penetration testing, and your traditional VM, because on-prem is never going to fully go away; there’s always going to be 15 to 20% of a company’s resources on-prem.
[12:39] And if all of these elements are dynamic and ephemeral, the software itself is updating and changing, the attackers are updating and changing, there are lingering vulnerabilities and legacy systems, every piece of that grows the attack landscape. When we have this giant attack landscape without a good process or a good way to prioritize, we just inherit technical debt that keeps growing. We really need more ways to handle this. We know, even without the data, just from being in the industry, that the number of vulnerabilities and the speed at which they need remediation are both increasing, security teams are overwhelmed, and the cost of addressing vulnerabilities is high, and it gets higher the later in the development pipeline you remediate. Why is that?
[14:14] First, when we have vulnerabilities on certain packages, once those continue without getting remediated, more containers and images leverage that, so we spread the problem if we’re not fixing it in time. In addition, the longer it’s out there, the more exploit kits get developed; hackers learn the vulnerability and how to leverage it and start making more tools to distribute those exploit kits, so it becomes more dangerous. And one more thing: a lot of the time we’re not even understanding the dependencies the application has behind the scenes; we’re opening connections to other applications, what we call SaaS security and those back-door, indirect vulnerabilities, and those are very important for companies to track, because people open yet another connection to a third-party SaaS application very easily. So that’s another hidden threat landscape, behind the scenes.
[15:45] It’s the Pandora’s box, because all those relationships, interconnections, and dependencies increase the blast radius, and it makes things harder. So we know the problem; let’s move to a solution. We think the solution is a unified playbook, and it’s all about aligning your technology, processes, and people. There are three key areas. Technology alignment is the easy one: by integrating security tools you get visibility into all your vulnerabilities, and by looking at the relationships and dependencies you can view the vulnerabilities in a prioritized manner if you have the right calculations on reachability, exploitability, and business risk, it’s all about your company. This is the easy part, because we have technologies, we at OX think we’re great, we think Seemplicity is great, and there are probably other tools you love. So technology is the easy part. Tomer, talk about the harder parts: process optimization and people empowerment.
[17:20] It has to become a really prescriptive playbook, because this is an iterative problem; it’s never going to end. So you put some automation in place that includes the connection between technology, people, and process. What’s amazing to me is that we still meet companies that use spreadsheets, and in security in 2024 that really raises an eyebrow, because it seems like a very inefficient process. They have to, because they have great tools, but each tool covers its own domain and prioritizes its own vulnerabilities, and then you have to put everything together, because there’s a critical on this side and a critical on that side, so which is more important? They turn to a spreadsheet. And when they try to hand that over to the people supposed to fix it, that’s where the friction comes, because they open multiple tickets for the same problem that could be fixed with a single solution, and throw it over to the other side. The person who gets that says, why did you give me 10 tickets if I could have solved it in a single place? A single ticket would have been a lot better and a much better use of my time. It’s about getting that trust, because the developers, DevOps, and DevSecOps people are starting to lose trust with security, because security is bombarding them with tickets. You need to gain that trust; those tickets need to be efficient and respectful of the person on the other side, and that encourages them to be part of the team when it comes to fixing security issues, because we know they don’t like it.
[19:58] We really need a good way to communicate, to get everybody on the same page, and to understand that both sides are necessary to enable secure software deployment. Now let’s talk about how OX and Seemplicity work together to provide a seamless solution from detection to remediation. OX Security works across the CI/CD pipeline and the development life cycle, so our detection and consolidation capabilities feed directly into Seemplicity’s remediation platform, and that integration reduces the manual effort a lot and speeds up the time to resolve issues. It’s about identifying, classifying, and prioritizing. Point two is automatic prioritization based on business risk, because not every organization is the same, not all vulnerabilities can be reached, and not all can be exploited based on mitigating controls. Our joint solution enables real-time collaboration between security and development teams, and the playbook helps eliminate delays and ensures everyone is on the same page. Tomer, tell everybody what this partnership does for their business, the key ways we drive value.
[22:07] There are two parts. On one hand we rely on quality data, the findings you discover and the context you put in, which we can leverage. Once we have the data, we consider ourselves a remediation operations (RemOps) tool, so it’s time to act upon it and orchestrate it. Part of orchestrating is making sure we can report and monitor to different stakeholders on posture, progress, and the SLA of the findings and the tickets, to measure that every person in this process is following the compliance the organization has set and meeting it. And orchestrating means operationalizing: opening the ticket, syncing the status, and checking that the ticket has been fulfilled and the finding actually fixed. We found that customers can spend somewhere between 20 to 40 minutes a month per ticket just doing all that. We have a large customer for whom we’ve opened 14,000 tickets and they closed 9,000, so in man-hours that’s a lot, and we’ve done it automatically. But we have to rely on good data, and then we help orchestrate that data into remediation.
[23:31] It’s all about remediation. You need the visibility up front, the correlation, good data, and then a playbook to orchestrate among people, process, and technology. Now to the exciting part: Aaron, show everybody how this works with Seemplicity and OX.
[24:04] Let me share my screen. What I’m going to bring up is the OX dashboard, and then I’ll have Tomer show what it looks like from the Seemplicity side. This is my own tenant within OX. The primary benefit you get out of OX is the ability to consolidate, bring together, de-duplicate, and then re-prioritize all of these issues we all know about. You simply connect your source code control and you get six scans out of the box; connect CI/CD and you get another scan; registry, another scan; and your cloud deployment method, two more scans. I’m bringing you directly into the issues, because this is where the rubber meets the road, and I’ll filter this down by Spring issues so we can zero in on particular problems. Within Spring we’ve got a number of issues corresponding to the count; some are direct and some are indirect, and OX will tell you with our severity factors, which is where the data we pass off to Seemplicity comes from. That allows Seemplicity to make decisions about how to remediate, and that’s where the power comes in. You can take a number of different actions from OX, and then Seemplicity amplifies it further. There’s a ton I could go on about with OX, but I want to focus on Seemplicity, so Tomer, take over and show what this looks like from the Seemplicity side.
[26:20] Jumping into the Seemplicity platform, let me give a brief description of how it works, starting with the mechanics, to understand how the data traverses from one platform to ours. When we look at integrations and data sources, we’ve got the OX connector connected in this demo environment, which was easy; all we had to do was put in the API key, and a couple of minutes later it’s there. I have a couple of other data sources here too, and the overall number of integrations keeps growing by the day across every domain in cybersecurity. The way we help customers make decisions is by a scoring ladder or a priority ladder, which you can think of like Jira severities, priority levels. Once we’ve done the collection, you’ll find all these findings, and focusing on what’s coming from the OX environment, we can see them here. Now that we’ve aggregated all those findings from all those tools into a single holistic place to view the problem and understand security posture in a single tool, it’s time to segment the problem according to how one would want to report and create different remediation streamlines. Every organization is built differently in how they want to handle and report things. I created a couple of options here: I can look at it from an XPM view and split issues between CSPM and ASPM, or between cloud and code, by office location, by different SaaS applications, lots of ways to go about it. When I look at the ASPM here, I’m looking at everything that’s basically OX, my demo environment, and I can create filters to focus on what’s important.
[29:11] As mentioned, we bring the information from OX, we see the severity, and we wanted to focus on Spring, so let’s do that. Now you see the Spring issues that Aaron showed in the OX Security tool. If I drill down into one of these findings, I get all the details provided by OX. This URL takes me back to OX, assuming I have access. I can see the environment and the specific resource it’s coming from, the severity, the status, the discovery time and other timestamps, how to remediate it as provided by OX, and other information. So very rich information. We also have integration with different threat intelligence. All this can be leveraged to prioritize: if we go to rules, I can create rules that leverage all those attributes, and decide what’s going to be a score or a priority. It’s much more accurate than a fixed risk score, where you’re not sure why it’s 74 or 68; here you specify exactly which attributes you care about and what the outcome is. For example, CIS plus EPSS over 90, I can use that filter for a specific scope and manipulate the severity, which impacts how tickets automatically open to the fixers. In resources we see the different resources coming from OX, the different packages as a resource, and the roles, the automations we have. For example, we can manipulate the data as soon as it comes in: some people want to automatically move findings that don’t have fixes into an exception, which saves time. You can define an SLA for critical things, very flexible, any combination of scoping and filter, and that’s for the entire finding life cycle. We also have customers who want to track the ticket SLA separately, measuring the people responsible for fixing the issues, breaking the finding SLA into the overall finding SLA and the ticket SLA to understand the performance of the people involved.
[33:28] So we’ve aggregated the problem into one place from all the tools, broken it down to how the organization is structured into remediation swim lanes and how they report to stakeholders, and now it’s time to look at the problem from a solution point of view, because a lot of problems can be fixed by a single solution. Aaron mentioned OX has aggregation capabilities, and we have them on our part too. In the OX environment here, I’ve aggregated a few things that have the same issue that can be fixed by a single solution, for example Log4j: you’d fix it in one place, creating a single fixed image that distributes to the different containers, a single fix. Here I aggregated all these unapproved licenses into a single issue, so when I open a ticket, it’s a single ticket encompassing all this information. We can also automate opening tickets by creating remediation queues. In this example the queue is paused because I don’t want to open tickets automatically now, but I’ve created a queue for everything coming from ASM matching this filter, with candidate findings. Once I define the queue size, say three tickets, that means when I start it, there are always only three tickets open in the fixer’s hands, because we don’t want to bombard the people on the other side; we open tickets according to the capacity the fixing teams have. We prioritize opening tickets by severity, SLA, and finding age, and we can play with that and the size of aggregation. Once the ticket is open, we always sync the comments and the status, so people can see where the ticket stands without bugging the person on the other side.
[37:05] Back to a finding from OX: say I know I have a single solution for all of these. Let’s mark four of them for this example. We have the capability in Seemplicity to create those rules automatically, so you won’t have to do this manually, but to reveal the process, it can be done manually: aggregate these findings. We work with customers to understand how they want to do this, whether they want to look at the same problem across different resources that have the same solution. Here we leverage AI capabilities, because once we aggregate multiple findings, we try to find the most common ground between them and provide a contextual title, description, and remediation, since the findings may differ a bit, so we use AI to regenerate the description and title to provide something contextual the fixing team can work with. Now these few findings become one. Let’s open a ticket, which can be done automatically with the remediation queue, but I’ll show it manually. I’ve connected Jira, but we support all the players: ServiceNow, Azure DevOps, Zendesk, Monday, and so on. I can map different attributes of the findings into the ticket; we have default templates, but people can modify the information, add assets, map to ticketing fields, and create the ticket in Jira. There are also ways to notify, Slack and email notifications, but for this demo we’ll focus on the ticketing side. Now the ticket is in Jira; I can see the resource, the description, the attached CSV containing the data, which is customizable. Any changes happen here, and I can see the ticket status is in backlog in Jira, and when somebody moves it to in progress and done, that’s reflected here. I always have the ticket information, the status, the Sprint, the due date, and any attachments and comments coming from Jira are synced here, bidirectionally, so we can push comments to Jira to ask what’s up if it’s not moving fast.
[41:03] The last part is the dashboarding, to track the posture and see if we’re meeting our requirements. Upper management and different stakeholders require different reporting, and we want to measure ourselves to make sure the process we implemented is efficient. We can see how many findings we’ve decreased just by doing aggregation; this is a demo environment so it didn’t decrease too much, but we have customers where we’ve decreased 90% of their critical calls. We can look at it from a scope point of view, where scope can be a business unit, an application, or a security segment, depending on how customers want to slice and report it. We can look at the breakdown of findings, not just who is the most critical but who has the highest ratio of critical, which takes into account the number of resources under that scope, a good metric to see if a scope is having problems. A breakdown from all the different data sources, and for AppSec we can break it down further. Customers can create as many dashboards and widgets as they want, with a lot around SLA and trends and the ability to create custom widgets. That was a very quick rundown of the platform.
[43:11] Thank you, Tomer, thank you, Aaron. For those on the webinar, feel free to enter questions in the chat, or if you want to talk directly with either expert privately, reach out after the webinar, and as a reminder this is being recorded so we can supply the replay. I especially like Seemplicity’s ability to track the SLA; I hear about that from our joint customers frequently, a really powerful way to optimize your processes and not bug people before they’ve expired their SLAs.
[44:08] It’s really about the quality data you provide, which lets us filter and zoom in on the stuff that’s critical, and do meaningful, powerful aggregations to focus on the solution side and consolidate as many things as possible, reducing the noise and being a lot more efficient with remediation, which is what needs to happen more, because you can only prioritize so much. It’s about understanding the root cause of the problem; a lot of the time it’s a chain reaction and spread from that root cause, so plugging this one hole can fix many issues derived from it.
[45:08] I agree 100%. The other thing I like is that all the decisions and business logic that OX and Seemplicity overlay and automate are also auditable. You can go in and, if somebody asks why you deprioritized this or increased the priority of that, you can see exactly why, so when it comes time to explain yourself to someone else, maybe an auditor, you have the data to back you up, and you can modify and improve your processes over time with that data too.
[45:44] Exactly. Once there’s more movement around the finding, we fill in the history of who changed what and who did what, which is trackable and important for auditors. We have that at the level of the platform, the activity, so every time something moves, because we know people need to report on that, and they know we do a lot of magic behind the scenes, so they want to make sure everything is tracked and modified. We also have AI consent, the ability to customize sub-statuses, and the threat-intelligence enrichment, so there’s other powerful stuff in the platform too.
[46:46] I notice we’re up on time. Thanks Katie, thanks Tomer, this is super helpful. Thank you to all of you joining us today, we really appreciate that you took the time out live. Let us know if you have any questions afterward, reach out and I’ll be happy to get you to the right person. It is Wednesday, October 30th, on this live demo; have a good morning, afternoon, or evening depending on where you are, and we hope to hear from you soon. Thanks Katie, thanks Tomer, thank you.
