
Hello everyone. Hope I'm audible. >> Yeah. Okay. So this is my first time talking. So please bear with me. I'm Avin. I work as a vulnerability analyst at discover. Uh so currently I work in application security team and as uh we have a separate vulnerability management team for application security and we have a separate one for infrastructure. Yeah. So today I'm going to discuss about uh some of the frameworks that we are currently using. We might be using but we might not be aware of that like that we are actually using those frameworks on our day-to-day operations especially in the vulnerability management space and also there are some newer frameworks probably new like SSVC and VX frameworks which really help us
uh prioritize the vulnerabilities. So I would like to get a quick uh show of hands. Uh how many are familiar with uh SSVC and VEX? Okay. Yeah, we have a room full of audience but not many are familiar with it. So I would hope that I can bring a good information out of this talk for you guys so that you can take this back to your uh company like kickstart conversations on these topics. um probably head in that direction. I want to put up a uh strong disclaimer that this is not something that we have implemented at discover. Um this is more of uh a talk based on uh the available publicly available frameworks where uh
security teams can like make use of these in their organizations and I'm not going to like uh disclose our talk on uh discover strategy. So hope uh that is clear. Um on today's agenda, I'd like to mention something about uh like today's challenges dealing with vulnerabilities and what are the new scoring systems that are available and also there are some things called as decision trees and there are some contextualization tools. I'd like to go over that and uh I'd like to try to provide some kind of real world example. uh uh I'd like to take an example of a zero day and how we can use these frameworks to like um uh kind of like address a zero day and um obviously
the most important thing metrics executive reporting and the communication and strengthening our own teams. So I would like to provide some kind of example strategies uh that can uh that we can make use of this. And lastly the questions. So what is the current challenge that we have with CVSS version three mostly nowadays we are seeing version four but uh most of the companies are still uh reliant on uh version three. So severity scores in isolation that means a vulnerability is only exploitable if there is a context just that uh some security researcher or like a vendor has done an exploit in his sandbox that doesn't mean that it can be exploitable in a company's environment which is
actually secured which can be internal systems. uh so things like that and also lack of uh environmental relevance same like that and also mixed ex uh exploitability insights that means um uh when the CV was out there might not be exploit PIS because it's available but uh at a later time let's say after 2 years or after 3 years some um bad vector or a security research might actually create an exploit uh which can be automatable and um like people can make use of that. So these are missing in current uh CVSS version v3s and always remember the theoretical maximum impact is not equals to like actual u uh exploitation and u you know this concept
of vulnerability chaining. So when an attacker wants to attack uh a system they just do not exploit a single vulnerability but they find a chain of vulnerabilities. So CVSS version 3 is missing this aspect and this needs to be considered so that we can lower our noise or reduce the um high number of vulnerabilities and better prioritization type of things and obviously the resources uh should be directed on the proper space not that we have to deal with thousands of vulnerability on a single day. uh and um regulatory scrutiny is um high over the vulnerabilities especially when it comes to PCIDSS compliance. So that's why we need to kind of clear our minds uh when
it comes to vulnerability management and focus on what's most important. So now there is this CVS version 4 available in the market. So what does that mean? So why there is a need for uh version 4 and what are the new things that's included? So too many criticals are there in version three and uh no thread context as we have discovered discussed and also lack of flexibility. Lack of flexibility means if the exploit uh is changing uh uh the the mode of exploitation changes it might be a automatic one or a manual exploit. So CVSS version 3 do not have any context to like uh to put these factors in. But version 4 has these uh
we can actually like put in concepts like attack requirements and user interaction can be like nonp passive active these can be like added into version 4 and um there is this new feature of like uh impact on subsequent systems uh that is included in the version 4 right now and also u uh there are um so CVS version 4 is from June 2024 uh that was included uh in NVD and the analyst are actually working on that. So there is also a plan for NVD to kind of convert all CVSS version three strings to version four strings by end of this year. But yeah, I'm not sure u how much of that can be possible by then but it's
on their website. Um and also there are some vendors uh nowadays they are releasing their uh CVS uh on CVSS version 4 strings and it's actually dependent on the security researcher or the reporter on what string that they are going to like um provide to NVD. So it's basically that it's not yet there but it's just coming in. So CVSS version 4 is a better one than version three in short. And uh how many here are familiar with EPSS? Okay. Yeah. So that is also not a great number but uh I believe uh the most important uh aspect of the talk today is EPSS. Uh because um it is kind of a machine learning algorithm that kinds of u predicts the
exploit in next 30 days. So that is CPSS scoring. So it is basically uh trying to take the data of that given particular vendor and their CV and their historical aspect like if that particular vendor has a CV in the last two years or last three years how it was exploited how many exploits were made available of that. So they kind of take that data into considerate consideration and they would be predicting the next 30 days score of that and there is this EPSS percentile thing. So based on the EPSS score the percentiles are given. So that scoring system is a direct like straightaway shot to like prioritize the most or highest number of EPSS
percentile or percentage we should concentrate that first. So that's basically it and there are also versions of EPSS um and let's say if you are using any venda tool for EPSS or you are getting open source data make sure that you are getting EPSS version 4 data there. So this is developed by organization called as first uh the same one as CVS uh developers. So they have this API integration link available on their website. You can uh directly go over there and get um EPSS data and integrated into your pipelines. And if you can see this diagram over here, uh the difference between version three and version four of EPSS is majorly the scoring. So in version three most of the
findings ended up having the highest score but uh there were significant improvements made in version four. You can see that score is like u up and down kind of like even u evenly distributed. This is really helpful to like prioritize better and um okay so exploitability context uh so vx so vx you might be already doing in your company uh basically triaging bomb uh trying to see if it is actually exploitable or not if the component is existing or not there's a slight difference between call flow analysis and vx call flow analysis is runtime um uh analysis this but vx is kind of a manual analysis where analyst goes and looks into the oss component and see if
that uh particular vulnerable component is actually used or not and there are four outcomes for a vex framework which is um which are not affected affected fixed and under investigation. So based on these uh these could be included to like better prioritize our things and I would like to call like have a call out or like shout out for all the security companies over there and also all the financial companies that make sure that you are requesting your sbombs uh from your vendors uh because um if we are not impacted by a vulnerability that doesn't mean that our vendors are not impacted by it right like it is always a risk for us. So if you have the data of sbombs,
it should be publicly available for most of the tools. So try to push your vendors in the direction. Try to ask uh their sbomb so that we are aware of the threat that our company is facing. Uh so that is about VX and SSVC. So this is a qualitative approach. There is no scores in this. This is also like um oh okay this is not um uh first organization this is CISA. So Carig Melon uh university kind of researched this first and then um uh CISA kind of adapted this. Um so there are four major outcomes for SSVC basically track and again track with an asterisk that is like um kind of um prioritize more uh
and attend and act. So act is the highest severity one over here. So uh in the next slide I'll explain like how we can come to these um end states but um mostly h I would like to mention one point about this is that please note uh this SSVC can be changed for any given organization like it can be customizable um not uh like CISA provided um decision tree is like actually not good with financial industry because there are some aspects of that which would not like properly align with financial industry but we can always customize that um by getting an idea of it. So this is the actual SS SSV decision tree like it's available in their website. Uh
so if you can see uh to your um uh right bottom there are only four mentions of act. That means if the exploitation is active and if it is automatable uh then if it is having a real technical impact or not and then um actually understanding between the uh differences between that. So if you if you like figure out that the impact is high or like medium then we might have to act on that but if it's not that then kind of like track or like attend to it or go after one week and like again review the exploitability status of that vulnerability kind of that. So if you notice here there is this thing called
as um u mission and well-being um uh so this is apt for healthcare industries but not actually apt for some other technological companies or of that sort. So definitely we can customize that u example um we can customize it based on internal versus external facing or um if it's any like PCI impacting or um things like that the data classification of it. So you can definitely customize that based on the organizational needs and this can be made use of that. Uh please note that VX and SSVC are more of like manual uh uh triaging uh efforts like for now like I I don't uh see a company which is which has automated this but this can
definitely uh be automated automatable. So that is basically about the four frameworks. Hope I'm able to give some like overview of that. There are so many resources out there like really good YouTube videos um from CSI itself that can actually dive deep into that given the time constraints. I'm not going much deeper into that. Um I'd like like to like focus on the process aspect like vulnerability management is all about operations like okay there are frameworks available there are like lot of processes available we have people available but how to put everything into a place and like take the most out of these frameworks. So I would like to present some kind of idea or a process that we
can actually implement. Uh so firstly um there are three major types of vulnerability management. you might be using a third party vendor uh to um like kind of aggregate and um have it in a single tool that's called as um ASPM tools or something and also you might have inhouse um u vulnerability pipelines or Excel sheets based so anything works uh just make sure that you have all the vulnerability data at one place including the CVE and the affected component and then uh try to integrate um that CVE in a way that you have its EPA score coming in and and also u some other details like if it is CESA KEV impacted like true or false
that data can be like integrated into that data. So now you have the vulnerabilities data and you have CVSS, EPSS scores and also uh the CISA key status. make sure that um these are on a day-to-day update basis like EPSS score updates on day-to-day basis and also CISA KV can be updated day-to-day basis and u uh I don't think that we can like directly start with vex it requires uh good amount of u um manual efforts but u there might be some processes existing in your company already which are kind of like doing this application security engineers might be doing this process So kind of integrate uh this with that uh if you figure out if a component is not
affected then that can be ruled out like right. So that way we can include that and also there are there is something called as EBPF based analysis and call flow analysis. These are runtime automatic analysis. So these are offered by some security vendors out there. So in case you have those tools um that can be a replacement of VX but not exactly a replacement like those are two different process but there is an overlap um and also once you have these things like you can rule out um um EPSS like if there are having like very low EPSS scores that doesn't mean that we should completely ignore them but if it has a high EPSS score then we definitely need
to act on that. So if it is not affected by vx uh like the outcome of ef vx is not affected so we can ignore that but if it is affected or any other of the outcomes then it needs to be prioritized. So if you can imagine like you can already see uh the filtering down of the vulnerabilities based on CVS eps and um vx and now comes the ssvc. So once you have this list of findings where there is like uh high criticality then you can pass it through this SSVC uh from your customized already customized um decision trees and act on only the ones where there is an act outcome like that could be a 15 SLA or
30 days SLA that should be treated as critical and um always uh the security tool severity is not uh the organization severity so that's why um we can definitely like uh risk rate our process using these four frameworks in a better way and definitely yeah as I've mentioned act attend and track based on the SSVC outcomes uh kind of a filtering process due to time constraints again I'm not going much deep into those um especially when it comes to a company some quick wins can be um first of all integrating EPSS codes and then integrating the KEV um so this this can be shown as huge wins when it comes to vulnerability management and also any company should
have their sbomb trials. So start with a pilot take one or two applications or a system and then start with um u gathering its sbombs trying to develop a platform of sbombs and kind of uh integrating that um somewhere so that you have uh a dashboard view of uh sbombs should be updated on uh day-to-day basis and also and I'm trying to give some kind of timelines um over here on the right um so for in the first uh two months you can use UPS like you can integrate EPSS and KEV and then Sbomb piloting and then CVSS version 4 integration. Version 4 integration means NVD kinds of um uh provides version 4. So make sure that your pipelines are
integrated with that and you are getting the version 4 details whenever available and um obviously in the next 5 to 6 months VX integration and code reachable team. This is some manual work would need more number of analysts and this is just based on like 5,000 to 10,000 company um 5,000 10,000 employee company and later at the end of this um then SSVC comes into place SSVC again it needs lot of understanding so uh piloting needs to be done and at last full integration so yeah saying is easy implementing is hard so just trying to provide an idea or an overview so that we kind of at least start the uh discussion towards this direction. So
that's all is my intent and um there needs uh an involvement of a lot of teams in this u uh like development teams, application security teams, even soft teams for threat intelligence and audit teams like um you should update your audit teams on on your new risk rating methodology kind of thing so that you just don't end up um having an audit finding on uh critical vulnerability just that tool tity says it's a critical it's not a critical one. So that and um try to like automate um um KV tag tagging, EPSS coding, sbomb generation, ticket creation. So if these are automated then it reduces lot of workload for the analysts at the end of
the day. So if um it is possible in your organization, try to do that. There are also vendors available out there who can do that and also advanced Excel skills might help. Uh that is that. Let me quickly look at the time. Okay, I guess I'm at time. I'll just uh breeze through it. Uh just in a minute. Okay, so there are some example metrics out here. I'll do something. I'll try to like share this uh presentation on my LinkedIn or something with my company's appro so that you can also go through this. I have tried to like u uh include some uh ways of executive reporting. It is really important and there are some
resources out there where you can like gain your knowledge or train your teams on that. So EPSS and SSVC are available on the first.org website. So all these resources are from that and vex is available out there on the CISA website and also there is the cyclonex.org website coming in from like OASP. They also provide very good information on vex and obviously there are organizational resistance when changes always hard to implement and um there are like tooling limitations and things like that. So make sure that you have um uh that listed beforehand and u uh make sure your uh uh staff is trained on uh these frameworks. They should have complete knowledge and also the executive
committees or the leadership should have an overview of what these uh frameworks are. So yeah overall um that is my talk. Huh. So thank you. [applause]
>> Thank you. Any questions? >> Yes. >> How do you differ? How do you priorize between a fast and CD. >> Yeah. So that's a really good question. So >> huh you repeat the question. >> Yeah. So the question is um so there if there is a dashed finding there is no CV associated with that. So how do I prioritize that using these frameworks um if I understand it right. So obviously SSVC and VEX comes into place uh when there is no CVE. So uh SSVC could be a better option but VX needs customization because VX is actually uh trying to understand um if there's the component available or not. it's more focused towards an sbomb. But if you can
customize it like you can try to understand that um um with a manual process if a dashed finding let's say SQL injection um so is it actually exploitable security tool can say it's exploit exploitable an IAS tool or a uh some other tool can say but what's the actual environmental context if it's an internal uh website which nobody can access. So it it can be prioritized like less uh manner and obviously these frameworks are more focused towards the CVE uh rather than that but yeah it's it's a good question. >> Yes. >> Uh how uh how successful have you been in actually getting sbombs from vendors and and the availability of them that that they're willing to
>> Yeah. So obviously that's a good question. Um obviously I cannot uh disclose uh about a discord strategy on that and I I really do not work in that area. So I do not have much information on esbomb's gathering but um u there were some talks that I've been to and this is kind of a norm in financial industry that uh JP Morgan first started this uh uh to ask it and u I understand it's kind of hard but um the direction needs to be set in that way so that if all companies start asking for sbombs for these tools maybe like uh things will start but if you do not start in the direction it would never like start
right. So kind of trying to just start the conversation in that direction that's all. [snorts] Yes. So how do you measure this like new method is better than existing method like what would be the main major matrix to evaluate this method? >> Major risks you mean? Uh it's like some like seeable like measurable some matrix I mean like some cost maybe or like human resources. Uh-huh. So I believe uh human resources uh is something because you need a skilled team who can actually understand these uh frameworks and also they should be able to like read the CV and understand what's what's the CV is talking about. just do not blindly take a security reporter's uh insight and uh consider
it's a critical one. We have to actually able to like map it to our own environment and try to like analyze that. So that is a major part of that human resources definitely skilled staff is required but also on the other side the technological aspect. Um um the better the integration works like the better it's automated then the better it can be implemented. If you are just uh doing it on an Excel uh spreadsheet, let's say you do not have any in-house pipeline or any ASPM vendor, then it's going to be difficult uh to actually like automate all these frameworks and all. So kind of both tech technological and resource. Yep. Both. Thank you. >> All right.
Thank you all. Thank you one and all.