Francesco CipolloneSession Video
About this session
Learn about the framework: https://phoenix.security/vulnerability-management-framework/
Session Transcript:
Dinis Cruz - 00:05 Hi, welcome to this Open Security Summit session, the first one in April 2023. We start with a bang with Francesco. She’s going to covers us on building Zealand application security programs. Over to you, Francesco.
Francesco Cipollone - 00:21 Thank you very much, Denis. Some technical hiccups, but we hear we’re ready to go. Thank you very much for everyone for coming and joining today, the presentation. We’re going to go through 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. I’m here today to show you the latest developments. It’s free for all to develop and participate and contribute. 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. There was a lot of guidance around secure development, lifecycle maturity elements.
Francesco Cipollone - 01:27 After you find the issue, what do you do with it? How do you triage? Who do you involve? How do all the different little pieces that form mature application security program, robulnerbility management program fit all together from detection to action and measurements and KPI, how do all these elements fit together? I think with the latest evolution of the industry, with risk based vulnerability management, the application security and cloud security coming together into a single CNAP, 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 insane amount of jokes and an insane amount of memes, because cybersecurity and application security in particular is half enough. Let’s start with a smile, let’s talk about with a smile. So let’s joke about it. On the first jokes, on the traditional slide, on the presenter, this can never fail, this can never miss.
Francesco Cipollone - 02:40 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. 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 executive that couldn’t get into the same page. I’ve been doing a lot of transformation from several financial institution to telcos. I’ve seen a lot of environment doing this. My question to you is, can we scale security to make it more enjoyable? A little bit more fun. Yeah, the answer is yes, we can. Vulnerability management framework is the first part.
Francesco Cipollone - 03:46 So what is a framework? Well, traditionally it has been around scanning everything that you can find possibly. This is definitely one part of a vulnerability management framework or detection of issue from software to vulnerabilities infrastructure, operating system and all the way down to the cloud. It’s not only that, it’s what you do with these things. How do you mature, how do you define who needs to what, when and to which level? This is all the purpose endpoint around the vulnerability management level. 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. 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 the modern security development lifecycle or security development framework and focusing then on deep diving in the vulnerability management framework.
Francesco Cipollone - 05:01 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. 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 chat GPT, new attack methods, script keydis and new developments. 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. 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 vulnerabilities that can be automated and scripted.
Francesco Cipollone - 06:19 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. This is 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 Kolis hasn’t released similar studies. Ponemon Institute have released a similar studies on how quickly are we fixing on average vulnerabilities across the board and where should we really focus. For me this feels like we are defending organization with 2013 mindset and defense, but having 2023 level attackers and this is only going to get worse.
Francesco Cipollone - 07:37 I know I’m reiterating the obvious, but things are getting faster quickly if you enable me the job. One input breaches has been proven to be derived from direct vulnerability exploitation of things that are externally facing. The time is now to actually think in a bit more clever way. 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 where we should really focus in 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 the vulnerability management framework to create that level of guidance.
Francesco Cipollone - 08:53 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 just that you will 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. From a software perspective it’s roughly the same amount. If you look at contextualization, roughly 10% of vulnerability are the only one that really need attention. If you bring additional context and intelligence, it will be even less. 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.
Francesco Cipollone - 10:04 The question is where do you start, how should fix things and what is the most urgent? 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. A haystack was on fire and everybody was screaming around me. Scaling this to organization, to large enterprise organization was particularly challenging. 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.
Francesco Cipollone - 11:08 And that leads to burnout. Shall I mention what happened to lawful J or spring for Shell or any other if you want us? 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, which 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. We all kind of remember and I guess have PTSD out of log for J. Do every lock for Jenny 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 buff, behind a compensating control? Probably not. The usually narrative that happens is the boats hear something on the news say do we have this problem, shall we fix everything?
Francesco Cipollone - 12:15 All hands on deck. The opposite element that happens is when security team says security is everybody’s responsibility. 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. Development team work and job is not to look at every vulnerability that any kind of tool speed out. Actually probably that’s the receipt for failure. What that generally speaking, end up being is us as a security team running, scanning solution and then checking over vulnerability to development team and screaming at them why can’t you be secure? The business screams at us why can’t you be secure? 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 for a specific amount of range.
Francesco Cipollone - 13:23 Usually it’s very few of us in an organization and is really difficult to triage be on every single vulnerability and be in every single scrum team or development team. Hence we give all this responsibility to the developer hoping that they have more time than us to actually develop. 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. 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 or to sit down to an architectural review or retrospective, there is a huge disparity.
Francesco Cipollone - 14:43 It takes quite a lot of time to recognize what to do with a specific vulnerability in the context of where that vulnerability happens. 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. We have roughly one to 201 security professional to 200 developers. 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 10 minutes per team per week. That means that we either 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 repeat that are critical. 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.
Francesco Cipollone - 15:44 The only solution is probably a mention and a 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 shift left and shift right and shift left mean bringing security very early stage in a security development lifecycle. We’re going touch in a second. 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. Also shift up and shift down means involving the business and having the business involved with us. Only in that way we can create a good collaboration across the team between product owner, between the business development and security. We’re missing one person in the room or a couple of person in the room, the auditor and regulators.
Francesco Cipollone - 16:44 Unfortunately there is a lot of regulation 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. Also there are mandate and statement of how many women are beating how quickly you should look at things. 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? Without a proper vulnerability centralization system and a mature program around it you spend that 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.
Francesco Cipollone - 17:59 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 not to cause panic but it’s really to describe the landscape where we are 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.
Francesco Cipollone - 18:57 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 resilience vulnerability management and application security program of work that enables you to operate at a risk level of an organization that an organization fund. 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.
Francesco Cipollone - 20:12 This is really what risk is and our objective is to reduce the risk service in the attack surface of the security team and operate at the level that the business is comfortable with. All this is done with vulnerability management, the framework risk management patching, fixing, implementing control, implementing a culture and so on. I probably spoke 25 minutes about the vulnerability management framework without showing you what is the vulnerability management framework. 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. There is a lot of debate around the team on creating a level zero or not. 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.
Francesco Cipollone - 21:20 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 vulnerability 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. 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.
Francesco Cipollone - 22:24 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. 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. 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. You have a left and a right and the left is the concept of shift left.
Francesco Cipollone - 23:31 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. The left is where I’d like to say you have fast triage and fast operational fast fixing. This is where you implement security technology and 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 or 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?
Francesco Cipollone - 24:43 This is where I call Fast reaction, fix it now or put in the backlog and then revisit it at next print 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. When logo J happened, local J didn’t appear in a library where 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 polina happen not in a development environment, but happening, production happening, laptops happen everywhere, exchange Vulnerabilities, the latest one that happened everywhere. This is where we need to monitor fundamentally production and we need to monitor what happened in an operational and production environment. 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.
Francesco Cipollone - 25:49 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. This is the backlog of fundamentally vulnerability that we need to tackle and decide who needs to do what where. 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. In the process of triage there is the correlation and the prioritization process where you look at which things should be addressed first. 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 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.
Francesco Cipollone - 27:14 This is the part that is enormously time consuming. Also the triage 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. 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. 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.
Francesco Cipollone - 28:16 Then do it. They don’t have to deal with who 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 our 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.
Francesco Cipollone - 29:23 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. That’s the purpose of the panel to then create a streamlined approach of things that needs to be fixed. 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. This is, if you think about it, vulnerability are just bugs are just defect. Development team have gone quite good at scheduling work to address defect and bugs, maybe doing retrospective and then continuing resolving. 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.
Francesco Cipollone - 30:34 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. 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. 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 APD 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.
Francesco Cipollone - 31:55 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 their 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? I understand the impact, I understand that this is potentially bad. 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.
Francesco Cipollone - 32:54 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. 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 scorecards in a very consistent way per application, per business unit, per organization. And they all interrelate together. The higher we go, the more abstract those element becomes. The lower we go those reporting, the more detail they need to become. 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.
Francesco Cipollone - 33:58 Because then when we have a complete disconnect of the objective of an organization saying, I want to be at risk zero. 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. 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.
Francesco Cipollone - 34:51 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 one, 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 element 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 are less software oriented house. Maturity three and four is where you start getting more into the automation and adding additional scanners.
Francesco Cipollone - 36:00 Maturity four is where you have the full part 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. 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? 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. The more scanner you have, the more noise those generate. 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 voting on focusing every development team on just the vulnerability that matters more and on the backlog of the vulnerability that affect them.
Francesco Cipollone - 37:11 What is the point of raising the 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. 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. This is where a lot of organizations lack because security at the lake is a new concept and security aggregation is a new thing. Traditionally you start 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? On 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.
Francesco Cipollone - 38:15 The next stage is the prioritization and then four and five is where you have automations. Here is where fundamentally 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. 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 ACA 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.
Francesco Cipollone - 39:12 Prioritization is the holy grail, is the most important aspect of things. 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 better, where you start using cyber threat 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. We’re working on CWE level 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. 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 assets or an application or a business service.
Francesco Cipollone - 40:39 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. 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 maturity three and four, start tackling down the backlog in a maybe more intelligent way or more proactive way. Four and five is where you start getting really proactive and looking at insight and statistics. There are tons of open source tooling available, not just Phoenix Security, but there is Open Bus and Defect Dojo, for example.
Francesco Cipollone - 41:39 They give you a lot of statistic 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. 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. 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 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 prospective. This has been highly debated on what are the metrics that really matters from an operational perspective versus an application security perspective.
Francesco Cipollone - 42:38 We have a consensus around, for example, the maturity one where traditionally vulnerability are being raised by criticality. You move reporting by SLA or number of vulnerability per business unit per SLA, things that are inside and outside a service level agreement. You move in maturity three where you have more business concept. Remember, maturity levels are also marked together, so you don’t necessarily need to be at specific stage. 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. The value stages of this framework are also interlinked together. In maturity five, probably some of this metric will be strickled 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. They probably are more common in maturity three and four.
Francesco Cipollone - 43:46 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. Specific KPI needs to be also mapped to specific persona. If you’re a business persona, you probably want to look at specific APIs 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. There is a whole debate, we just done a whole debate one of a form that I love the most that is less full security around this specific subject to our discussion this. 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.
Francesco Cipollone - 44:54 We’ve been talking about going to the moon without the step necessary to get there. 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 these issues 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. All of this is supported by the vulnerability management framework from detection left and right to measurements to action. This is what a modern observation security program works. If you haven’t seen as well, there is a blog where a couple of these images are taken.
Francesco Cipollone - 45:53 This betterupcycle.com is a fantastic resource for a lot of these additional information together with us. 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. I would like to leave you with fundamental message.
Francesco Cipollone - 46:57 I created this and we created this framework and we created Phoenix as well to prevent burnout. Don’t just be complacent and just deal with criticality their vulnerability because this leads to burnout. I would like to mention as well that we have all of this documented in application security vulnerabilities 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. Phoenix security does fundamentally vulnerability management triage prioritization enable you to communicate from a risk perspective. Close pitch parentheses, but we are partner as well with OS. If you have an OS account, please. You have access to both the AbSec part of it but the full platform for free. 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 other leaders in application security that is available to download for free.
Francesco Cipollone - 48:15 SLA dead and Long leave SLA and a data driven approach on application security. So we are probably few minutes away. I’d like to thank you everyone for your time that you dedicate to me. I’d like to open the floor to questions.
Dinis Cruz - 48:39 Yeah, man, this was great. It’s like a master class on application security, man. Sorry. 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.
Francesco Cipollone - 49:03 Did I shock everyone questions?
Dinis Cruz - 49:06 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.
Francesco Cipollone - 49:20 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 of vulnerability management framework. Some of this stuff is freely available to use. It cool. I’m going not no question.
Dinis Cruz - 49:43 No, I don’t think so. So I think we’re good.
Francesco Cipollone - 49:45 All right, good stuff. Thank you everyone. Please remember to download the framework and use it and give us feedback. Hopefully.