 All right, so it's almost 3.05, so we'll just get started a little early, I guess. I'm Katie Bratman, and this is Adam Kojak, and today we're going to be talking about S-bomb ingestion and analysis at New York Presbyterian Hospital. So today we're going to go over S-bombs. They probably address some technical details about them. And then we'll talk about Daggerboard, which is an app we built to analyze S-bombs. And then I'll pass it over to Adam so he can talk the technical details on Daggerboard. So this is our Daggerboard development team at New York Presbyterian Hospital. We're all part of the information security team, and we're really excited to be here with you today and be presenting Daggerboard. We're announcing that in partnership with the Linux Foundation, we've open sourced it and put it on GitHub, and we're really excited. We encourage anyone that wants to contribute or wants to use it to join us on this S-bomb journey. But before we start talking about Daggerboard, let's start talking about the problem. Why are we actually here today? And I like to think about the problem from my perspective on a hospital network. So on our network at the hospital, we have a lot of unmanaged devices. Usually they're in the form of medical devices, and those are notorious for having some pretty bad vulnerabilities. So we can think of these medical devices as closed boxes, basically. We don't know what they do. We know they're sitting on our network. We don't know what is in the box or what they're built out of. So even if we wanted to know what these were built out of, if we asked the vendor, up until recently, there wasn't a great way or a standard way to provide that information. And this leads us to a bigger problem. There's no software transparency. And when there's no software transparency, we can't tell confidently what vulnerabilities are present on our network. We also can't tell what needs to be licensed. For example, we could probably scan these closed boxes with a vulnerability scanner, but that's only going to give a partial picture. To get the full picture, we'd have to open up the box and inventory all of the items inside or decompile the software. I know not everybody has time to do that in their daily jobs. So what we have is a lot of complexity and a lot of unknowns. And in the security world, if you don't know what's on your network and don't know what to protect, things get complicated and hard really fast. So to address some of these problems, the software bill of material or the S-bomb was released. And an S-bomb, it's just a machine readable XML file that for a given software component tells us what the dependencies are and then what licensing data is there. When S-bomb first came out, it was met with some questions. People weren't really sure, how can we implement this? But then there were a few industries that took the challenge and hit the ground running and have adapted the S-bomb standard. So this is why we're here today, actually. The first group to use the S-bomb standard was the healthcare S-bomb proof of concept group. And we're a member of that. And tomorrow, our CISO Jennings Aske will be talking at 945. He'll give a keynote on that for more information. And I would say definitely go check it out. But basically our proof of concept in healthcare was so successful that a few other industries followed us with a similar practice. And then to show that S-bombs have become more popular, an executive order was announced last year that said if you do any business with the government, you have to provide an S-bomb for your product. So what this means for you is if you haven't seen S-bombs already, you'll probably see them in the future because they're not going anywhere. And so we know that S-bombs were intended to be used for vulnerability analysis, but within an actual S-bomb file, there's no vulnerability data. And they're also in XML format. So they're machine readable, not really human readable, which means I'm not gonna sit there and read through an S-bomb myself and try to find what vulnerabilities are here. So this means we need something like dagger board to automate and do that analysis for us. Now, when we think of a nutrition facts label, it's actually pretty similar to an S-bomb. Because an S-bomb, it just lists the ingredients that were used to build a software component. But what the S-bomb doesn't give us is the rest of the nutrition facts. So the other big part of nutrition facts are the consumption details. Let's say I'm eating food. I wanna know how much fat this is gonna introduce into my diet for the day and do I really wanna do that? So we knew that that was a gap in S-bombs and we decided, let's make something that finds this information and gives us the full picture. So we started by trying to add this information into our sims, Blunk, but things got complicated pretty quickly. And we knew from there, let's make it easy. We wanna be able to just upload an S-bomb and our ingredients into an app. Have it do the analysis and just spit out the results. So this is where we get dagger board. So dagger board takes the S-bomb, it parses the results, and then it gives us basically a risk. It tells, we can use the results from dagger board to determine, do I really wanna put this on my network? Do I wanna consume this risk? So more on the S-bomb here. We have an example of an S-bomb file in black and white on the slide. Again, it's XML base. There are two supported formats, Cyclone DX and SPDX. And you might be wondering now, how do I get my hands on an S-bomb file? There are a few common scenarios. The first one is, if it's a commercially available product, you'll probably have to ask the vendor or the manufacturer for that. But the second case is, if you're working with an open source product, you can use tools like SIFT. We actually have SIFT in action on the slide, or some other tools to generate S-bomb files. So let's dive into the S-bomb now. Just like any XML document, the S-bomb, it has a bunch of tags and metadata, and there are four tags that we use from a vulnerability analysis perspective. Well, okay, the first tag we have here is the document name. And that's gonna tell us the name of the software component we're analyzing. The second tag we have is the creator organization, and this is just the manufacturer of that software component. And so with Daggerboard, we use these tags together for identification. Our third tag is the package name. And our fourth tag is the package version. So keep in mind, an S-bomb file has a lot of different packages listed. So we're gonna see a bunch of package names in there. Now, here's what we can do with those tags. So we take the package name and the package version and put them together, and try to get a CPE string. And if you're not familiar with the CPE string, it's just a standardized way to identify software. It's this long string you see on the slides in orange, and it's really commonly used for vulnerability identification and analysis. So what's really cool about the CPE string is, it's maintained by NIST in the National Vulnerability Database. And this means they basically attach it to a vulnerability. So once we have a CPE string, we can then say, hey, and we can query the National Vulnerability Database and say, hey, tell us what vulnerabilities are relevant here. So now that we know at a high level what we're doing with Daggerboard, we're gonna start to get into some of the actual problems we ran into along the way in the development process. And keep in mind, when we were building this app, we were actually using proof of concept S-bombs from the healthcare working group. So those were also in development, and it was a really collaborative process. We got to work with the people from the group and get feedback. So the first issue that we ran into was, how do we map an S-bomb file to an actual product? Because sometimes we saw some random software components and as from the perspective of a user just using this app, it was a little confusing. What we found initially was, it really depends on who's providing and creating the S-bomb. But since then, something called the VEX document has been introduced. And the VEX document, for a given product, will have a list of relevant S-bombs in the metadata. But right now, the VEX document's not totally complete. Once it is, we do plan to integrate it into Daggerboard. So the next problem we ran into was around package names. And this was around the package name tag, but we'll touch on that more in a moment. And finally, we knew that we wanted to map a package to a CPE and then a CPE to a vulnerability. But when we started to put this into practice, we noticed some inconsistencies. Basically, what we did was implemented a two step approach to fix this. So now what we do is on a daily basis, Daggerboard will take a cache version of the National Vulnerability Database and store it locally. So when an S-bomb is uploaded in real time, it's checked against our local database and then against NVD in real time. So onto our package and consistencies. We can see in this notepad here, there are three different examples of .NET framework and these came from three real S-bombs. But what we can see is the package name technically never matches, it's always different, and the package version is kind of crazy too. There's a verbose version number, then there's some just 3.5, a lot of craziness. And what we decided from this was we can't really trust what we're given. We need to clean this data and then take a tiered approach to match and find CPE strings. So what we'll do is we take the package name and then take pieces of the package version and first we'll clean them and then try to match them and piece them together and look for CPE string matches. And with some analysis, we found that this was a much more accurate approach than just taking what we're given. So the problems we'll cover now are some of the things we ran into along the development process with the code. So the first thing was when we loaded vulnerability data into our app, we started getting errors and this one was really simple. It was just because older vulnerabilities only had a CVSS2 score in some cases. Easy fix, just add a calculation for CVSS3. Now our next problem is related to one of our goals of Daggerboard. It was we want this to be simple. What can we do to help the analysts prioritize the problems that they find with the S-bombs? Now when it comes to vulnerabilities, we know that criticality is one way to do that but it's pretty vague and maybe it doesn't always get the full picture. So we added an additional check that for a given vulnerability, we'll see if exploit is publicly available. The next one, this came from lessons learned from the healthcare working group. We found that some vendors felt that S-bombs files were private. They didn't want them to be public. So this means we need to treat them as sensitive data and this means our app needs to be protected by authentication. So what we did, we wanted to leave this flexible and we give the user the option between using LDAP and local authentication. Easy enough, of course, we were using Django. They have an LDAP app that we can just take. But it didn't turn out to be that easy and we ran into some issues where it didn't really like that we didn't provide the LDAP information by default. So we had to extend the app to get it to work the way we wanted. And finally, this one was probably the biggest problem for us that stuck for a little bit. It was do we add the calculation of letter grades and if so, how? The reason why we had some questions about this was we know that grading can be kind of questionable, sometimes it could be tricks even. But at the same time, not everybody in our organization that's looking through these results is deep in the weeds and technical. They need a high-level overview and this is where grade can really come in handy. So we decided let's go with it and did some research on how other vulnerability scanners do their risk scoring and grading. And then came up with a method to do that on our own. So I'm gonna turn this over to Adam now to get into the more technical components of Daggerboard. Good afternoon, everyone. My name is Adam Kojak. I'm one of the developers for Daggerboard at New York Presbyterian Hospital. Very happy to be standing here today and not being impaled by that thing, whatever that was that fell. So really glad to be here and present more on Daggerboard to you all. So it's been a long time in the making. We've been working on this application for about a year and a half. It started off as a side project, but over the course of a few months, we turned it into a real thing. So we're very happy to be presenting this to you all. So this slide here, this represents the concept when we first started building the application. So what pieces did we need that were the components of the application, starting at the web framework? We built the application using a Django web framework, mainly because we're a Python job. And out the box, the admin configurations are pretty easy to implement. So that's where we settled with the Django framework. Scanning and parsing the S-bombs, this is the nature of our application. We need to be able to effectively scan every S-bomb, no matter what format it is in Cyclone DX or SPDX, and be able to parse that information necessary so we could pull it from the NVD database. We also need to be able to evaluate and assess the infrastructure risk. So what kind of letter scoring are we going to be grading these S-bombs based on their severity scores? Are they going to be in A, B, C? Or they could be ultimately up based on the significance of the criticals or severities that each one scores. We'll go more into the grades in depth later. LDAP and local authentication. Local authentication comes out of the box already. But we need to implement LDAP into this application, mainly because there is sensitive information in there. So using local LDAP integration, you're able to add that to your organization. Our back-end administrative controls, and if anybody that needs to upload the S-bomb, they'll have to read or read write access or anybody who's able to just read or analyze the data, they'll have access to read. Fancy charts and graphs, what is an application without a fancy chart or graph? We have all the fancy charts that we could add to it. We're talking bar charts, line charts, spider charts, name any graph, we added it to the application and it's useful for the analyst at the end of the day. And most importantly, we developed this application to be open source. So we're announcing it now and we released this on GitHub a few days ago. So being at the open source, so I'm very happy and pleased to be announcing that. It's been released and it's able to be used for anyone and everyone, no matter what the organization is. We are coming from healthcare, but we're open to any organization to contribute. So everyone and everyone is welcome to use it. All right, so how does the process work if you have DAG board? So coming from a supply chain's perspective, it mainly is based on the vendor or the manufacturer to provide the S-Bomb. It's everything else from there on. It's basically we select the product, we get provided the S-Bomb, upload a DAG board and we assess the risk from there on. It makes it really easy. I don't really need to go into the slide in that detail. I'm sure I'm very aware that everyone's aware of all these frameworks and packages and modules, but this is just a slide just to comprise of what we built the application on. So think of it as the picture logo of an S-Bomb. You see our basic front ends, we have bootstrap, all that. And in the back end, we're using a Docker container to unpack and install, as well as in the Stolar script and we're using MariaDB as a database in the back end. All right, so we didn't really talk about how does the process work under the hood. So Katie mentioned that you get a CPE that matches to the S-Bomb that's uploaded. But what happens from there on? So you can see here, there are two events that are triggered. We have a scheduled job in the back end that reaches out to national vulnerability database to pull the necessary information from there. And then an event is triggered when a user uploads the S-Bomb. From there, we match that data. We match it against the CPE and get the CVSS scores from there. And from there, we enrich the data even further because we were able to match it. So we reach out again and we enrich the data. And if we are not able to match or enrich data, we generate a common outfound. But if we are, guess what else we do? We enrich the data even more. And from there, we enrich it more. And this is coming from exploitDB based on the CVE. So that way we're able to produce the vulnerability results. And from there, we store into our database. All right, let's talk about grades. So I did mention this before. And grades are subjective based on your organization or grading scheme or your policy. So based on how many criticals, how many vulnerabilities you have, it could be biased or significant to one side or the other. In this case, it's this basic math. We did weight, multiplier, we did weight severity, weight scores. So based on those counts, how many criticals we're retrieving from national vulnerability database, highs, lows, mediums, and then we just divide it by that total and we've retrieved the grade threshold. And within that grade threshold, that's where you have your A, B, C, D, F. And that's where you're able to. But this is not a default. You're able to customize this on your own. So we added that feature just recently. But let's go over a little example. It goes like, we can see that we got a SBOM with 15 critical vulnerabilities. That's pretty high. I mean, what kind of grade can you guess for this one? I mean, just based off of that, we got two highs, two mediums, two lows. I mean, this is obvious that this would result on a grade letter F, right? So the significance is there. But let's say that you had five mediums, five highs. I mean, it could get a little subjective on that front. So based on that, you're able to customize your gradient scheme within the application. All right, let's talk about the roadmap ahead. So we built the application. It's released on GitHub. But what else do we want to do? We want to enhance the reporting analytics for an executive summary to be scheduled on an ongoing basis. We don't want to have the analyst that has to report every single time. We're in an automation business. Let's automate that. API integrations. We want to release an API that can integrate with any product, any of your products. We want to enhance the search functionality. So at the moment, we're not able to search by CVEs. So we want to add that feature where you're able to search by CVEs. And like I mentioned, we released this on GitHub. So please, you're all welcome to contribute. All right, so that concludes the slides. We're going to go over a demo. So let's turn on the application and show you guys. All right. All right, great. So welcome to the login screen of Daggerboard. As you can see, I don't know if you're familiar with what a Daggerboard is, but it's part of the sale boat. And like the sale boat, it symbolizes to keep your company afloat. You don't want any holes in there that will sink your ship. And let's log in. All right, welcome to the dashboard. All right, so starting at the dashboard. So starting at the dashboard, you can see the last two S-bombs that were uploaded. On the dashboard is pretty much a front page that presents all the data up front. And just to mention, the data here is just for demo purposes only. I don't want anyone from Apache saying, hey, why did you grade my S-bomb in F or anything like that? So no scrutiny there. So you can see the last two S-bombs that were uploaded, what their severity, how many counts of severity they had that were uploaded. In this case, three criticals highs. What the overall grade was, you see in the second to last one. Down here, there's a highlight of all the S-bombs, of overview of all the S-bombs that were uploaded. Total vulnerabilities, 479 in our demo environment. And not sure why the presentation's small, but we're just gonna enhance it, because yeah, let me just try that. Entering my super secret password. All right. That's better. Thank you. All right, and at the table at the bottom, you can see that those are all the, that's a historical table of all the S-bombs that were uploaded to date. Let's move over to the S-bomb. Page. So this page is a detail on all the S-bombs that were, on specific S-bombs that were uploaded. And let's look at one, for instance. Let's pick elastic search. All right, so let's analyze the elastic search, and this is not real. Just for demo purposes, again. All right, so the grade letter is F. How many vulnerabilities were found? The total severity distribution amongst that S-bomb that was uploaded. Spider chart to show the vulnerability impacts. This is a package analysis of all the packages that were in that S-bomb. You can see which ones we found, which ones we're able to find. So those are all the packages. And then if we get into the vulnerability details, and this is where we're pulling from exploit DB, you could see the severities, as well as the exploit that's available. And there's a link there that you can go to, to see that. Last page, the vendor page, overview of all the vendors that uploaded S-bombs on a vendor level. Let's pick our friend Apache. Oh, Apache's already there. The grade. Line chart that represents how many, a line graph that represents how often S-bomb is uploaded from this vendor. Total severity distribution by vendor. What the last analyze S-bomb was, as well as a history of all the S-bombs that were provided from that application. I went from that software S-bomb, all right? In this section here, when an S-bomb is uploaded, we are uploading it here, in this section here. And just for timing, it does take a while. So if you're parsed, it does take time to parse. But to view the progress of the S-bomb, you could see that in this area, as well as the recent ones that were uploaded, all right? So that goes over to the pages. Let's move on to the administration section. So in here, this is what makes Django great. Out the box, you're able to configure as many administrative configurations as you want. And starting with authentication and authorization, you could modify your groups, who to add to read only, write, upload. LDAP, you could configure your LDAP environment to your organization. Users, you could configure your user base. In this section here, you're able to modify the database if you have to. So we leave that there. And the grading schemes and the grading weights thresholds could be defined in this section here. So depending on how significant you're weighing towards critical high severity, that could be configured there. That concludes the demo, that concludes our presentation. We are very thankful everyone attended this presentation. Do we have any questions? Yes, sir. So the vulnerability data from exploit DB, is it being filtered on the particular platform and other variables such as this? Because I've seen stuff on exploit DB that's very specific to an individual platform having that software. Does it take that into account? At this point, it's only focused on the CVE. Right, but within that CVE, there's nothing, it doesn't do any filtering. So if that CVE is linked to the CPE, so the software CPE, then we take that CVE and see if it's an exploit CVE. Okay, cool. Sir. Okay. Imagine, I would imagine that there would be like a lot of devices, right? And that you would first have to inventory the devices and then probably in the future have some sort of automation to actually find the S-bombs. Otherwise this would be very cumbersome to find the S-bombs and then reach out to whoever owns the device to ask them for an S-bomb. And I don't know if you do that via email or if you could share in terms of the processes involved of actually getting the list of devices and then getting the S-bombs for each of you. Because this is starting from a point where you've actually uploaded an S-bomb, right? Right, yeah. And so internally for us, we're going through that process now where with some of our vendors, we're starting to make agreements in our contracts that when they buy a new or when they provide a new device, it has to come with an S-bomb. And then with our internal process, that would probably go to our risk team who would then have dagger board and upload it to dagger board. Hey, I'm sorry, I'm Jen Exoske, I'm the CISO for NYP and I've been one of the folks working with the Linux Foundation on this whole concept of S-bombs for a couple of years and tomorrow I'm giving a keynote and I'll talk more about the question you raised. We need to get to a point where S-bombs are just something that happens and it's not this unusual thing. And we have the first example of that with the Biden administration's executive order saying you gotta give an S-bomb if you sell to the federal government. But how do you do that? How do you make it electronic, end to end and it's not like you're uploading a file. So dagger board is like us like contributing to the community, starting this effort but we have a project and I'm looking at my friend Kate back in the five or six rows back, she's part of it. We're actually right now getting ready to like make this electronic end to end and something that doesn't depend on a person doing something, right? So there's a web service, there's something that's coming and this is an evolving thing. We mentioned VEX is part of this presentation. It's coming to where we want this companion document that explains like, all right, S-bomb says these software components and then the manufacturer has the ability to say like these are the vulnerabilities that you should be concerned about or not concerned about. So a lot of thoughts going into this very evolving thing and I like to make the analogy to HTML 1.0. If you're old like me, you remember like going to websites and people like, there's a guy like a digging construction digger and like there's those bad gift images. That's where we are with S-bomb and the reality is that this is meant to start a community project where we just start this and we make it as simple and usable as possible but we're not there yet but we're working on that actively. Like how do we make this where there's no one like Katie uploading a PDF file from some vendor because that's not sustainable, we all know that. We have I think 1400 different medical device manufacturers at NYP. Like how would we keep up with that? So that's where like this is a start and that's our goals to start a community project and then like build APIs we showed and all those things. So question and they should answer. I shouldn't talk. I'm not supposed to talk. Thanks James. Does the S-bomb provide an opportunity to verify what software is actually running? So if someone either leaves something out on accident or maliciously on the S-bomb to actually confirm that the software is running what it should be. So at this point, no, it's all do you trust, you should, well, do you trust the S-bomb you're getting yet? But again, it's a work in progress. Is there a roadmap for that or an opportunity within the XML or the documentation to provide something like that? We're welcome to add it to our features list on GitHub at this point. Hey, so I think this is a good example of what Eric was talking about in terms of curation this morning, right? So a curation of this stuff is pretty valuable. Do you currently have any vendors that are producing VEX, the vulnerability exploitability exchange documents for you? I'm curious. So that is currently like ongoing work with the healthcare S-bomb proof of concept. So they do, but I don't think they're final at this point. They're still going through rounds of is this good? What else do we need to add to it? What changes should we make? And would you say that it's a necessary supplement to S-bombs? There's not some suggestion you would make to add that data to the common S-bomb formats, like to an S-bidex file or? Yeah, I mean, I think it could help, but as an idea, VEX does seem to be pretty helpful. We just need more information to supplement that, yeah. Because the VEX document, again, it includes relevant S-bombs for a product, but it includes other things, like whether or not a vulnerability is relevant and whether or not it's been validated. So it puts it all in one spot at least. So at Anaconda currently, we're producing that kind of data in our own sort of format. So it'll be interesting to look and see if that's something we can use additionally or instead. Yeah, yeah, that is interesting. So you've gone through that before then. Have you found a need to diff S-bombs when you're working with vendors, like verifying, for example, something was taken out or something was added? So I saw where you could upload the S-bombs and see the evolution of grades, but I'm just curious if you ever have the need to look at component differences between the S-bombs. Yeah, so at this point, we don't have a feature that does that, but it would be some, it's worth adding. That would definitely be worth exploring, yeah. That's very helpful. Okay, cool. Thanks for sharing this, really cool. Thank you. Hi, thanks for sharing. I saw that S-bombs has a large focus on vulnerabilities. I was just curious what the thought process was behind leaving off licensing for open source components. And if maybe it's something that might be added in the future, because obviously open source has a lot of licenses that don't play nice. So I was just curious about that. Yeah, and so actually S-bombs does focus on licensing as well. We're just taking the perspective of vulnerability analysis. Maybe that's biased because I'm on the vulnerability management team, but it is definitely, I think, the licensing aspect could help an app like this too. Okay, thank you. Thank you. Hi. What is the story? So you get things ingested into Daggerboard. What is the story after from the analyst's point of view? Because for instance, at our organization, there's lots of tools that our analysts have to go through, Splunk searches and other dashboard custom stuff that we have. What does it look like for your organization or in your experience at least? Yeah, so I think it's pretty comparable to scanning a device with a vulnerability scanner. So you scan the device, you wait to get the actual list of vulnerabilities, and then you look at the solutions for those and kind of determine where to go from there. So for us, it's similar. You'd upload the S-bomb, get your vulnerability output and the solutions, and kind of determine what to prioritize, what to follow up on. I'm kind of losing my voice, but... So Daggerboard connects, put a report on that too, and thank you. So we can use it from a vulnerability perspective. If the device is already on our network to find, is it vulnerable to this? Do we need to implement any other safeguards? But also from a risk analysis perspective, I think, where when you're getting a device in, you don't really know what you're getting, and so it kind of gives us a full picture. And I mean, even before you purchase a product, you could probably get an S-bomb and analyze it that way. Okay, yeah, I was like from, I guess from the new product coming in, but also are you guys doing this retroactively on things that you have already running there and kind of how your analysts are, like for instance, investigating based off of like, okay, we now know we have a log for J device on the network. Now we have to go through six months of logs to make sure like, did anyone tamper with something or whatnot? Is that something that y'all are doing just out of curiosity? We are not currently, but that would be the idea yet, because like right now I would go into like my vulnerability scanner and see historically like, go log for J's here, and this would just be another repository to go through. But I mean, hopefully that's why adding an API would be really helpful because then we could have like all of that information in some central location if we needed to. Cool, thank you. Great, any other questions? Are you finding now that you're starting to hold your vendors accountable that actually they weren't as aware of the amount of vulnerabilities they actually had in their products? Coming from the developer side, building the app, I mean, generally, we're more focused on getting the application up and running. Leadership is more focused on that. I think like also if anything, maybe this has made them more proactive and willing to provide that information. And we've seen in general over the past few years, vendors have been much better with disclosing like, hey, we're vulnerable to the log for J vulnerability, for example. Has there been any need to add any sort of exceptions for any of the CVE data that comes through for the different packages in NASBOM? Yeah, I think that's a really good question. There has not been yet. Right now, I mean, if you wanted to, you could go in and remove it. We don't have like a formal, you can add an exclusion that expires after this point though. Okay, great, if there's no other questions, thank you very much.