The Presentation From Francesco Cipollone Walk you through the vulnerability management framework, the history, the evolution of the application security maturity, into the vulnerability management framework. The PDF of the presentation is available here

WHY WE CREATED THE VULNERABILITY MANAGEMENT PROGRAM FOR APPLICATION AND CLOUD SECURITY

Vulnerability Management Framework project is an open source (GPL 3) project sponsored by several vendors but completely vendor neutral. It’s free for all to develop and participate and contribute.

Francesco Cipolone is the CEO and founder of Phoenix security startup. His mission is to prevent burnout and make everybody live a happy life on security. Today he talks about the vulnerability management framework. Why is this framework really needed across the industry?

Attackers are getting faster at exploiting vulnerability from recent studies for critical vulnerability, three to 15 days from declaration time is the exploit stage at scale. One in four breaches has been proven to be derived from direct vulnerability exploitation of externally facing things. In order to get to the moon, we need a step by step approach.

HOW TO PREVENT SECURITY TEAM BURNOUT

Security team checking to development team all the vulnerability across the board. This results in an enormous backlog of things that might get overlooked. This is the good road to burnout for both aspect and both element of the table, both the security team and the development team.

THE VULNERABILITY MANAGEMENT FRAMEWORK

The current published version of the Vulnerability management framework is divided between five levels, actually six with level zero. The framework in itself is divided into detection, aggregation and management, prioritization action and measurement. Now we’re going to analyze fundamentally where vulnerability come from and how normally an application security program is put together.

WHAT IS A TRADITIONAL APPLICATION SECURITY PROGRAM OF WORK?

What is a traditional or what is a modern application security program of work? This can be also described as a vulnerability management program where you have more less security design and secure build but more tests and secure operate. This is how a modern security pipeline with all the controls is created.

HOW TO STRENGTHEN THE VULNERABILITY MANAGEMENT PROCESS

The panel aims to transform a traditional chaotic and slow vulnerability management program across different parts of the organization into a more sausage factory and resolution factory. The more we go forward, the more everything is going to be engineering structured and at the pace of an engineering sprint.

VULNERABILITY MANAGEMENT FRAMEWORK: MATURITY 4,5

Right now the vulnerability management framework is at version 1.2. We’re already working at 1.5, enriching a lot of the detection, prioritization action and a few others elements. How do you evolve your scanning capability? The more scanner you have, the more noise those generate.

MIXED FRAMEWORK: MONITORING AND REPORTING

The last part but not least important is the measurement. This is probably the area that is being developed the most and in this particular version of the framework is least developed. It has been debated on what are the KPI and measurements that make sense at every stage.

SHIFTING THE BALANCE BETWEEN APPLICATION SECURITY AND VULNERABILITY MANAGEMENT

The Phoenix Security Vulnerability Management Framework is available for everybody to download for free. Don’t just be complacent and just deal with criticality their vulnerability because this leads to burnout. Is SLA dead and long? Leave SLA and a data driven approach on application security.

—-

Transcript

thank you very much for everyone for coming and joining today, the presentation. We’re going to go through a little bit of intro on why we created the vulnerability management program and how to build resilient application security, cloud security and vulnerability management program.

This is a community effort that we kick off last year and has been developed over the course of the years with several industry members vendors participating in building the Vulnerability Management Framework project, that is an open source project sponsored by several vendors but completely vendor neutral. And I’m here today to show you the latest developments. It’s free for all to develop and participate and contribute.

Intro

We built this for a specific reason because there was no much guidance for how to solve issue other than when we found the issue. So there was a lot of guidance around secure development, lifecycle maturity elements. But after you find the issue, what do you do with it? How do you triage? Who do you involve? And how do all the different little pieces that form mature application security program or a vulnerability management program fit all together from detection to action and measurements and KPI, how do all these elements fit together? And I think with the latest evolution of the industry risk based vulnerability management, the application security and cloud security coming together into a single scene up, this was very much needed and hence why we put it together.

So, without further ado, let’s continue, and I hope you guys excuse me because I’m going to use an a lot amount of jokes and an a lot amount of memes because cybersecurity and application security in particular is half enough. So let’s start with a smile, let’s talk about with a smile. So let’s joke about it.

And on the first jokes, on the traditional slide on the presenter, this can never fail, this can never miss. So my name is Francesco Cipolone for who doesn’t know me. Frank for friends.

I’m the CEO and founder of Phoenix security startup here in London and Europe that revolves around software security, maturity aggregation, prioritization, but fundamentally my mission is to prevent burnout and make everybody live a happy life on security. My why my ethos is because I’ve been through this, I’ve been through several vulnerability management transformation. I felt the pain of actually triaging, dealing with tons of tickets, dealing with tons of frustrated developer and security professional and executive that couldn’t get into the same page.

Background

I’ve been doing a lot of transformation from several financial institution to telcos. So I’ve seen a lot of environment doing this. And my question to you is can we scale security to make it more enjoyable, a little bit more fun.

And yeah, the answer is yes we can. And vulnerability management framework is the first part. So what is a framework? Well, traditionally it has been around scanning everything that you can find possibly.

And this is definitely one part of a vulnerability management framework or detection of issue from software to vulnerabilities in infrastructure, operating system and all the way down to the cloud. But it’s not only that, it’s what do you do with these things, how do you mature, how do you define who needs to what, when and to which level? And this is all the purpose endpoint around the vulnerability management. So today, as I mentioned, we’re going to talk about the problem and where are we and why are we here and why is this framework really needed across the industry? Why it was very much vocalized on why it was needed, the issue and human cost of actually triaging and fixing vulnerability manually that has exacerbated in the recent year.

And I wanted to bring some data and metrics together with some studies that have been available in the industry and then we’re going to dive deeper on a little bit the modern security development lifecycle or security development framework and focusing then on deep diving in the vulnerability management framework. I’m going to stop a certain section for everybody to ask question and then we’re going to wrap up at the end with why the Q and A. So let’s start with a fundamental question why do we need a vulnerability management framework or why do we need some guidance or why do we need vulnerability overall or managing those vulnerabilities? Well, let’s start with the more obvious thing that everybody knows, but I think it’s useful to reiterate attackers are getting faster and faster with charge EPT, new attack methods, script keydies and new developments.

Why attacker are getting faster

Attacker are getting faster at exploiting vulnerability from recent studies for critical vulnerability, three to 15 days from declaration time is the exploit stage at scale. And that’s probably one of the elements that I want to hone in and probably hammer during this presentation is the at scale part that has been particularly hard in the recent years because fundamentally attacker are getting clever and clever on orchestrating and scheduling attacks at scale using well known vulnerability that can be automated and scripted. The resolution time has been dramatically squished, especially for things externally facing, but also we’ve seen things that are also internally facing in an organization being at risk in some level of stage.

And this is a little bit of a diagram of how the history have changed from 2013 where the average resolution time and exploit time, sorry, was around 80 days for a critical vulnerability from the date of discovery to all the way down to 2021 and forward where the vulnerability resolution time is around 15 days. Three to 15 days roughly right now is the average and some statistics around average time that this one of the recent Garner studies. But Kohlis has recently released a similar studies.

Panamanian Institute have released similar studies on how quickly are we fixing on average vulnerabilities across the board and where we should really focus. And for me this feels like we are defending an organization with a 2013 mindset and defence, but having 2023 level attackers and this is only going to get worse. And I know I’m reiterating the obvious, but things are getting faster quickly if you enable me the job.

And one in four breaches has been proven to be derived from direct vulnerability exploitation of things that are externally facing. So the time is now to actually think in a bit more clever way. And I want to maybe reiterate as well the fact that right now we’re focusing on really taking vulnerability and everything that we find from different security scanners and I’ve listed some of them at the bottom of the pyramid.

While we should really focus in a little bit of a clever way to actually do that, that is contextual, that is CTI based exploitation, that is looking at things that really matters and stuff that really needs fixing. The challenge is a security professional. We all say we should be there and the question is how do we get there? In order to get to the moon, we need a step by step approach and hence why we created a vulnerability management framework to create that level of guidance.

Because not everybody needs to be around the moon. Maybe in your organization, maybe you can be well off just looking at what are the exploits available in the one. Because even with debt, even with just that, you would shave off an enormous amount of vulnerability, at least from a software and operating system perspective and container perspective, it will reduce drastically the amount of vulnerability that you will look at.

APPLICATION SECURITY PERSPECTIVE

And from a application security perspective, it’s roughly the same amount. If you look at contextualization, roughly 10% of vulnerability are the only one that really need attention. And then if you bring additional context and intelligence, it will be even less.

But without intelligence, without context, without any information, where are we standing? This is the modern security development lifecycle after an organization have implemented maybe one, two or three scanners and you try to dump information in a security data lake, or you might look at different security dashboards, you have tons of criticals from different scanners, completely uncontextualized, completely unrelated together. And the question is where do you start, how should you fix things and what is the most urgent? And to me, when I started this life in application, security and vulnerability management triaging at scale, I was overhelmed and to me it felt like finding a needle in a haystack. But a haystack was on fire and everybody was giving around me.

scaling Application Security to large enterprise organizations was particularly challenging. And how are we fixing it so far? What are the methods and approach that we’re fixing it so far? Well, we put a security team in front of a huge backlog of vulnerability to triage across all the landscape that we have, plus looking at cyber threat, intelligence and then trying to find the vulnerability matters most and being that rake that fundamentally shifted and reduced the number of vulnerability to a minimal level, to the 10%. But that’s not scalable.

And that leads to burnout. And then shall I mention what happened to lawful J? Or spring for shell or any other, if you want, as one of my good friend Alyssa says, the superstar vulnerability that every hands on deck, everything needs to be resolved in every kind of repository or in any kind of library or in any kind of operating system. With Paulina was across the board a very well known Microsoft vulnerability log for J was the other well known one that happened during Christmas last year.

And we all kind of remember and I guess have PTSD out of log for J. But do every lock for J to be resolved? Probably not, but we have the capability to say which one should we resolve? Which particular instance of lock for J is actually behind a walk, behind a compensating control? Probably not. And usually narrative that happens is the boats hear something on the news say do we have this problem, shall we fix everything? All hands on deck.

And then the opposite element that happens is when security/appsec team says security is everybody’s responsibility. And what that really means usually is checking to development team all the vulnerability across the board and that results in an enormous backlog of things that might get overlooked or might not get overlooked. And development team work and job is not to look at every vulnerability that’s any kind of tool speed out actually probably that’s to receive for failure.

And what that generally speaking end up being is us as a security teams or application security teams running, scanning solution and then checking over vulnerability to development team and screaming at them why can’t you be secure? And the business screams at us why can’t you be secure? And the reason to do so is because security team. In any organization that I’ve been dealing with, when you’re lucky, you have 15 application security people or a specific amount of range. But usually it’s very few of us in an organization and it’s really difficult to triage be on every single vulnerability and be in every single scrum team or development team.

And hence we give all this responsibility to the developer hoping that they have more time than us to actually develop. So this is the good road to burnout for both aspect and both element of the table, both the security team and the development team. The developer don’t want to deal with tons of vulnerability, the security team doesn’t want to be in every single scrum looking at every single ticket because that’s not scalable and average this was last year, we have 570 more developer than a security person.

An average amount, I would say, of security to development in a small organization is one security person for every 50 devs and that if you take a nine hour vulnerability triage versus a 48 minutes time, that a security. Professional can dedicate to a development team to analyze a vulnerability, to sit down to an architectural review or retrospective. There is a huge disparity.

It takes quite a lot of time to recognize what to do with a specific application security or infrastructure security vulnerability in the context of where that vulnerability happens. And then if we take you to the extreme of any large organization that we traditionally deal with the development community keeps on growing while the security community doesn’t keep pace. And we have roughly one to 201 security professional to 200 developers and the number of hours and the number of times that the development community can dedicate the security community can dedicate to the development community is up to ten minutes per team per week.

So that means that we ignore a bunch of application and we just focus on maybe two or three that are critical and we dedicate the right time but we need to know which one are actually critical and which one are the repeated are critical. And this is why I say this is the right road to burnout. And I’ve been there.

I feel a pain. I’ve done that. And the only solution is probably a mention or shout out to a team of sage.

And this is Tanya. Jank has recently shared this and I really like the idea of sorry for the low resolution image. Was a last Windows edition, but shifting everywhere.

We’ve been talking about appsec shift left and shift right and shift left mean bringing security very very early stage in a security development lifecycle. We’re going to touch in a second and shift right means fundamentally still looking at vulnerability and what happened in production and there is not either or both of them needs to be there. But also shift up and shift down means involving the business and having a business involved with us and only in that way we can create a good collaboration across the team between product owner, between the business development and security.

But we’re missing one person in the room or a couple of person in the room, the auditor and regulators. Unfortunately there is a lot of regulation around vulnerability management. More coming from the European for the new Cyber Resiliency Act and from the recent bomb and all the conversation of the Cyber Resiliency Act from the US.

But also there are mandate and statement of how many vulnerability and how quickly you should look at things. And unfortunately those are statics and static information, static declaration. They don’t look at prioritization, they don’t look at maturity, they don’t look at where you are.

They just ask you where are the vulnerability? Have you fixed the report? Have you done these things? And without a proper vulnerability centralization system and a mature program around it you spend up time and effort of security or development running around colliding report and I’m going to make this available through PDF. We’re not going to go promise across every single regulation that there is around vulnerability management but there are more and more statements around vulnerability management that are coming out and more that will come out. I want to make a quick postal and take a step back what is the real objective of security? Because right now we’ve been down the rabbit hole of oh my God, there are vulnerabilities everywhere oh my God, we don’t have enough time, oh my God, we don’t have collaboration and there is new regulation.

This is not the purpose of the presentation, it’s about to cause panic but it’s really to describe the landscape where we are at in appsec and our thinking of where we should go and what is the real objective. The real objective is not to fix all the vulnerability altogether but to involve the business to define what and where we should be at a specific point in time. Where should we be from a risk perspective and risk for who knows? Me I love risk because risk enable us as a security professional and development to communicate with the business and having the business communicate to us.

But also it’s really important because enable us to describe where does a business want us to be, against whom we should defend, against which level do we want to deploy our security team and not fixing all the vulnerabilities? Also because fixing vulnerability, as you can see here on the right is just one of the elements of a vulnerability management program like implementing security control, influencing culture, implementing things in a shift left way, implementing fundamentally controls at the very early stage like threat modeling or guardrails at the very early stage. All of those things forms part of a single but united vulnerability management framework that enables you sorry, resilience vulnerability management and application security program of work that enables you to operate at the risk level of an organization that an organization fund. And I wanted to reiterate vulnerability in itself are not risk vulnerability on an asset described by a threat that has a particular probability of an exploit to happen and a particular impact.

This is really what risk is and our objective is to reduce the organizational and appsec risk service in the attack surface of the security team and operate at the level that the business is comfortable with. And all this is done with vulnerability management, the framework, risk management patching, fixing, implementing control, implementing a culture and so on. So I probably spoke 25 minutes about the vulnerability management framework without showing you what is the vulnerability management framework.

So drum rolls and let’s show so this is the current published version of the Vulnerability management framework is divided between five levels, actually six with level zero. And there is a lot of debate around the team on creating a level zero or not. But it was a good way to show that this is when you don’t do anything.

Usually organization operates a maturity level one. The framework in itself is divided between detection, aggregation and management, prioritization action and measurement. Those are the various pillars of the framework with a maturity level across each one of them.

Now we’re going to go and analyze fundamentally where appsec and cloud security / infrastructurevulnerability come from and how normally an application security program is put together, and then come back to the vulnerability management framework on every single vertical of this and dive deeper. So that you have more context around where do we start and where do we end, and why is the framework structure in this way? So let’s start with the first part. What is a traditional or what is a modern Application security program of work? I like to represent this in this particular way where you have at the central part the three core elements of an application security program of work.

This can be also described as a vulnerability management program where you have more less security design and secure build but you have more tests and secure operate. So it is applicable on both way as well as cloud security where you have element of design, build and test with infrastructure as a code and creation of environment. And then on top of that there is governance and open size, risk management and risk management framework, cultural change and education.

We’re not here to talk about all of that area. I would like to focus on the central part because it’s a central part that generates fundamentally issue vulnerability and also enable us to mitigate. So when we generate vulnerability and I know this is a bit huge to digest, so I’m going to go slowly on this.

This is how a modern security pipeline with all the controls and all the scanning technology is created. You have on top fundamentally automated scanning solution and at the bottom process and procedures that are enabling the process and enabling security professional to operate. And then you have a left and a right and the left is the concept of shift left.

So when you build and when you test and the definition of the dotted line is when you deploy in either dev test or production. Definitely speaking, what we refer here is production. So the left is where I’d like to say you have fast triage and past operational fast fixing.

This is where you implement security technology and Application Security tool like code Analysis or Sea secure library checks, where if an issue is get thrown at the developer or at you, as a security professional SRE, you can quickly make a decision either to fix it because you have something in your IDE in where you develop the code that flat red and says there is an issue here or a potential issue here, or there is a library. When you build the code, when you commit a specific segment, this is where I call Fast reage. Now you can make a decision can I fix it or is this going to cause more issue around the code or is this going to cause a number of incidents? This is where I call Fast reaction fix it now or put in the backlog and then revisit it at Next Sprint or Retrospective.

This is some quick decision that you can make. And then the right part is where things happen in a more consistent way, like when Loj happened. Loj didn’t appear in a library where we were writing code, but appeared everywhere.

Either if the library was deployed, if the particular piece of software was deployed in production, was a Java virtual machine or image deployed in production, or if you take for Lena happen not in a development environment, but happen in production happening. Laptops happen everywhere, exchange vulnerabilities, the latest one that happened everywhere. So this is where we need to monitor fundamentally production and we need to monitor what happened in an operational and production environment.

And this is a shift right where we look at where vulnerability happened and they traditionally don’t have somebody on the keyboard at that particular point in time, with the exception maybe of the sock. But this is where fundamentally you have either complex triage or complex impact assessment of a vulnerability and you need to decide how to tackle this backlog. And this is the backlog of fundamentally vulnerability that we need to tackle and decide who needs to do what where.

And this is the challenging part of the vulnerability management triage and why a lot of the time we created the framework. So what is the process of triage? As we said, I like to see it in a three step process where you discover things from various scanners, either in a fast fixed way or in an operational way, scan it, aggregate all this finding in a central place and then triage deciding which one is important. And in the process of triage there is the correlation and the prioritization process where you look at which things should be addressed first.

And then comes the fun part, finding the right team where this vulnerability needs to be addressed or the right repository, or the right people, even if you’re lucky that that particular application is maintained by a specific set of people and then chasing and following up, maybe raising an exception, maybe that’s a false positive. This is the part that is enormously time consuming. Also the three ash correlation and prioritization can be enormously time consuming but this can be automated in a certain way.

Chasing, following up, alerting reporting can be gamified if you develop a security champion program, but it’s definitely time consuming. Also planning, following up resolve and making sure that the vulnerability was actually resolved. Is the other action part kind of sits at the border, but I would like to maybe look at also the other side of the world.

Where we have to deal as a Blue Team, as a Purple Team with a lot of politics, deciding what to fix, when not to fix, what time to allocate. But on the other side, you have attackers that still have their own organizational structure they need to discover. They need to identify a good target to attack prioritizing, maybe which vulnerability to attack first.

Then do it. They don’t have to deal with we need to fix what yes they have right now their own development tool and they’re becoming especially for ransomware software house but that’s not the operational people the one that goes in attack they don’t have that time or that expenditure of time to spend on dealing with politics. Well us as a defender we have to and this is a process that tend to be linear from a resolution time.

We scan issues, we visualize sorry, we scan issues, we aggregate, we visualize, we triage, we remediate, we resolve and we go back to the original step to rescan and verify this is the traditional process and how it happens sometimes I used to think that this was linear, it’s actually not. I think it more now as a funnel where on top of the funnel you have two kind of source of information. You have everything that happened in your software and everything that happened in your environment, infrastructure, container, cloud and so on.

You aggregate all this information in one single place on multiple places. You prioritize, you deduplicate and you contextualize each of these process enable you to screen and reduce the number of vulnerability or things that you should look at. And that’s the purpose of the panel to then create a streamlined approach of things that needs to be fixed.

And that’s how you operationalize and scale a traditional chaotic and slow vulnerability management program across different parts of the organization into a more sausage factory and resolution factory. And this is, if you think about it, vulnerability are just bugs are just defect. And development team have gone quite good at shadowing work to address defect and bugs, maybe doing retrospective and then continuing resolving.

And the more we go forward and the forward we go, the more everything is going to be engineering structured and at the pace of an engineering sprint. So if we align Security sausage Creation Factory and issue Creation Factory into the structure and process of a development team, then we’re winning because we ensure that the development team can then or the engineering team can then schedule work in a consistent way and focusing always on what’s more important, but also having process and procedures to support them. Now this in the easy part and airport for who is listening of structuring and shadowing work but then how do we report on all this? Because KPI is the other very important part and aspect of reporting either to the business or to the virus team.

And if we choose the wrong KPI, this is how we end up looking. Or this is how I remember looking when I was talking just about vulnerability to any community that wasn’t dealing with vulnerability. If I was talking about a specific apt group that was attacking a specific vulnerability that was behind not behind a firewall or not behind a WAF and hence had the probability of getting exploited of x amount of time or board member they would just get completely lost.

What the heck are you talking about? And they were right, they’re dealing with business unit, they’re dealing with line of business, they’re dealing with country, they’re dealing with a lot of risk. Security is not in their day to day dealing, not at least at that detail level. Well, if I talk about risk position or amount of money that an organization could lose or the reputational damage maybe that an organization could lose to a developer, an engineer will say what do I need to do in Next Sprint? Understand the impact, understand that this is potentially bad, but what is the stuff that I need to do? So that’s the two aspect or the two pyramid elements of reporting that I would like to mention that is at technology level we have specific KPI or specific objective.

If you use the system of OKR, that matters and that are really useful. How many vulnerability do you have? What is the time to fix vulnerability meantime to resolution? Or what is the mean time to open? All these elements really work well at this level which is the most critical asset, which is the most critical vulnerability? But the higher you go in the chain the more abstract those reports needs to be. We need to aggregate the number of vulnerability.

Maybe we need to convert them in risk. Yes, because enable us to communicate with the business and create spoke out in a very consistent way per application, per business unit, per organization, and they all interrelate together. And the higher we go, the more abstract those element becomes.

The lower we go those reporting, the more detail they need to become. But it’s really important to keep them linked together. We can’t have the risk level to be in a spreadsheet that express risks that are not totally correlated to number of vulnerability that we have or the state of the control that we have on a specific system.

Because then when we have a completely disconnect of the objective of an organization saying, I want to be at risk zero. And an engineering community says or a security community that says, if you want to be at risk, really zero, you need to deploy a small army or a small country budget to actually be at that risk. Well, if you.

Express the number of vulnerability, the number of risk of each application, and you enable the business to say, I want to operate at this risk level. You can quantify and you can schedule work in a consistent way and in a way that is aligned with their expectation. And that’s where you create reporting and expectation and you enable the business to operate at the risk level where they want in engineering and security to collaborate and create that triangle of collaboration that is shift up, shift down, shift left and shift right.

So shift everywhere. All right, so back on the vulnerability management framework. We’re going to dive deeper on each of these sections and describe which of the various vertical they are.

Right now the vulnerability management framework is at version 1.2 and we’re already working at 1.5, enriching a lot of the detection, prioritization action and a few others elements that enable you to assess in an easier way and also scope in a more way.

The detection part is specifically important for dealing where you find things and we kind of divided them in an evolving way where you have a maturity one and two, maybe the beginning of an application security scanning or an infrastructure scanning or a Pen test scanning. That’s usually where an organization tend to start, depending if you’re a more software oriented house or you’re a less software oriented house. Maturity three and four is where you start getting more into the automation and adding additional scanners.

And maturity four is where you have the full park of scanner that traditionally a software house or a modern enterprise has, that is API scanning, sea manual testing, Pen testing, maybe a bug bunty program, and so on and so forth. And maturity level five is where you start automating some of this control, putting them inside the pipeline, operationalizing scanning, it at scale. Again, you don’t necessarily need to be a level five.

You need to ask your organization which level do you want to be? And that enables you to plan step by step every year. How do you evolve your scanning capability? The following step is aggregation and deduplication from a lot of those scanners. And the more scanner you have, the more noise those generate.

So the more you need to reduce the number of noise by either consolidating all these problems and really laser focusing every team that really matters and we’re going to cover that in action. And routing on focusing every development team on just the vulnerability that matters more and on the backlog of the vulnerability that affect them. What is the point of raising a ticket with the development team of a vulnerability that is sitting on an application that they can’t support that create noise, that create confusion? So the more scanning you have, the more likely is that a data lake that you create, all the information that you present to a team becomes noisy.

This is the nature of it. But this is where a lot of organization lack because security data lake is a new concept and security aggregation is a new thing. So traditionally you start by aggregating, by aggregating vulnerability and maybe represent them, maybe represent the vulnerability by criticality.

It’s this critical, how many critical do we have, how many vulnerability from a low medium perspective do we have? Then maturity two and three you start enriching and aggregating things by business unit, by maybe application. That’s where you start getting more into the concept of enrichment and helps as well. The next stage this proprietarization and then four and five is where you have automation.

So here is where polymetry you need more heavy work on deduplication and removing duplicated from every application or every scanner or aggregating things together. For example scanner that scans an IP address externally and scanner that scans an IP address internally. Or maybe libraries are not being used or maybe different repositories that are being scanned in different and multiple scanner.

And this is traditionally what happened with a lot of organizational maturity three or four that they may be grow by acquisition and you have different business units and different teams that then have their own scanning capability. Maybe you have an SCA tool in one organization and an ICA tool in another organization and that fragmentation doesn’t enable you to operate in a control way. That is where aggregation deduplication really comes handy.

And then prioritization is the holy grail is the most important aspect of things. So the prioritization aspect operates on bumping up and down vulnerability based on different elements. Traditional organization in maturity one and two operates around SLA or what needs to be solved, at which specific time for a specific criticality, where the organization gets a bit better and clever as maturity Two and three, where things get a little bit better, where you start using Cybertrack intelligence, possibly at scale to operationalize and really prioritize the vulnerability matters more.

There are several framework like EBSS exploit prediction scoring, that is an open source available threat feed to at least look at the infrastructure. And we’re working on CWE level so software vulnerability to at least prioritize the vulnerability that are attacked in the world that are more likely to get exploited in the next 30 days. And then a maturity four and five is where you start moving towards a more risk based approach, a more contextualization approach and bringing in really the concept of where an asset is and how business critical is a specific set of asset or an application or a business service.

And this is where you get a bit better and you start aligning fundamentally in a more business way, in a more risk way, in a more modern way. Your vulnerability management program or your application security management program, the action part is what you do to then scale down and action on the vulnerability. And traditionally this approach in maturity one and two is reactive react on the vulnerability that gets raised to you from a few vulnerability perspective.

On maturity two and three, you start reviewing a backlog because maybe you have a backlog of vulnerability that you have available and you start a maturity three and four, start tackling down the backlog in a maybe more intelligent way or more proactive way. And four and five is where you start getting really proactive and looking at insight and statistics. And there are tons of open source tooling available, not just Phoenix Security, but there is Open Bus and Defect Dojo for example.

They give you a lot of statistics and insights on what is the most common vulnerability that you have or what is the most common issue that you have or which one is the most vulnerable asset. And that’s in maturity four and five where you start getting the security team more proactively operating and tackling at scale vulnerability. Netflix for example, is really good at this, creating paved way, removing vulnerability altogether or classes of vulnerability altogether.

And then the last part but not least important is the measurement. And this is probably the area that is being developed the most and in this particular version of the framework is least developed because we’ve been debated on what are the KPI and what are the measurements that make sense at every stage and every organization have different metrics and perspectives. So this has been highly debated on what are the metrics that really matters from an operational perspective versus an application security perspective.

But we have a consensus around, for example, the maturity one where traditionally vulnerability are being raised by criticality. Then you move reporting by SLA or number of vulnerability per business unit per SLA, things that are inside and outside a service level agreement. And then you move in maturity tree where you have more business concept.

And remember, maturity levels are also marked together, so you don’t necessarily need to be at a specific stage. But if you don’t have any concept of business context, you can do SLA based on risk, you can do SLA based on specific other elements. So the value stages of this framework are also interlinked together.

And in maturity five, probably some of this metric will be trickled down on different level because meantime to resolution build versus fix, that is, how many user stories do you have versus how many stories you don’t have. The property are more common in maturity three and four. So we’re still debating on where to move these things.

This particular area of the framework as well, the debate is around the element that we saw before that is who look at various metrics and reporting. So specific API needs to be also mapped to specific persona. So if you’re a business persona, you probably want to look at specific KPIs that are based on risk.

If you’re not a business persona, if you’re a technical persona or a security person, or a developer, you probably want to look at KPI that makes sense to you like how many stories do we need to build versus how many things do we need to fix and metrics like that. And there is a whole debate, we just done a whole debate on one of our form that I love the most, that is let’s talk security around this specific subject to our discussion on this. But without further ado, let me wrap up probably the conversation that is we’ve been hearing and talking about shift left, shift right, shift up and shift down.

We’ve been talking about going to the moon without the step necessary to get there. So I would like to recap that a mature application security program or a vulnerability management program or a cloud security program. For me they’re interchangeable.

They all deal with defects and they all deal with defects. When you write code, that is in the left and when you run things that is in the right and aggregating and consolidating all this issue in a central place so that you can triage in a bit better way, manage exception and create executive reports but also an engagement with the development team cleaning up those information. And all of this is supported by the vulnerability management framework from detection left and right to measurement to action and this is what a modern application security program works.

If you haven’t seen as well, there is a blog where a couple of these emails are taken. This betterupset.com is a fantastic resource for a lot of this additional information together with us.

So wrapping up vulnerability management can be daunting and at the beginning for me was overwhelming the amount of tasks and people that I needed to talk with. So identify where you identify the issue. This is my recommendation decide the maturity level, where you are and where you want to be.

Collaborate and sit down with team and define which team can move faster and which team can move slower. Talk with the business, shift up and shift down. Get commitment from the business and then talk with the development and security.

Shift left and shift right for me and implement the vulnerability management program and framework. Give us feedback as well. Use the framework, give us feedback, let us know what you think and let us know how to fix.

But I would like to leave you with fundamental message of this. I created this and we created this framework and we created Phoenix as well to prevent burnout. So don’t just be complacent and just deal with criticality their vulnerability because this leads to burnout.

So I would like to mention as well that we have all of this documented in Phoenix. Security Vulnerability Management Framework is available for everybody to download for free. We are making as well a collaborative project and integration with Tson in the upcoming future.

Shout out to us a little bit. This is what we do operationally. So phoenix security does fundamentally vulnerability management.

Triage prioritization enable you to communicate from a risk perspective. Close pitch parenthesis, but we are partner as well with OS. So if you have an OS account, please, you have access to both the appsack part of it, but the full platform for free.

And this is our commitment to the community as well. On the subject of metrics, we have dedicated a whole book written with the community and few are the leaders in application security that is available to download for free. Is SLA dead and long.

Leave SLA and a data driven approach on application security. So we are probably few minutes away. So I’d like to thank you everyone for your time that you dedicate to me.

And I’d like to open the floor to questions. Yeah, man, this was great. It’s like a master class on application security, man.

Sorry about yeah, I was just checking with Adam. I think again, let’s create lots of small little nuggets of this because I think it’s a really good one. I’m not seeing any questions here.

Did I shock everyone? I think we wowed everybody. And the slides, I keep getting better, man, every session. You’re making some really amazing slides that I feel like I just want to use them and do all my presentations.

Feel free to use it. This is my commitment to the community. It has a copyright, but feel free to use a lot of these slides.

The vulnerability management framework. Some of this stuff is freely available to use. It cool.

I’m going to it, no question. No, I don’t think so. So I think we’re good.

All right, good stuff. Thank you everyone. Then please remember to download the framework and use it and give us feedback.