IATC - #SBOM is here: making progress (not excuses)

welcome everybody uh this is panel discussion today is on software bill of materials and we have with us fortunate to have a great panel that we're going to discuss and talk about where we stand today with it and where we plan to go with software bill of materials or s bomb as we've got to let her speak first

so uh katie would you like to introduce yourself yes sure hi i'm katie bratman i work at new york presbyterian hospital as part of the vulnerability management team and also as part of the daggerboard development team we'll be talking a little bit about daggerboard today it's an sbom analysis tool adam hi i'm adam kojak um i'm um a developer at new york presbyterian hospital as part of the information security team alan i'm alan friedman i'm from the government i'm here to help i'm from sisa and i'm the guy who doesn't shut up about us bomb and lastly my name's christopher gates i am a medical device developer and an expert in embedded product cyber security and i've worked with alan now

for seven years on various projects something like that yeah so the first question here is uh why do we need an s bomb so if you go to the store and you buy a twinkie it comes with a list of ingredients uh to me it's just kind of baffling that the most important software in the world doesn't have the same level of transparency as we expect from a non-biodegradable snack uh the important analogy of sort of that list of ingredients that list of ingredients by itself won't magically save you but one would you buy from someone who couldn't tell you what they were encouraging you to eat or in this case have your life depend on so

the value of doing it even if you can never touch the data yourself you still want someone to know that they have it but the other thing is right you can't do all of the things that we might do with a list of ingredients uh right protect your family from allergies vulnerabilities uh follow a uh a certain religious based restriction right the analogy there might be hey i don't want things from certain types of development environments or countries on my network for certain reasons so it really enables a lot of great data to say or it's the data layer that allows us to sort of think more broadly about different kinds of risk um i'll let you guys jump in about why

it's important for your orgs yeah so we work in healthcare and where s bombs really come in handy for us what we're seeing is with medical devices so oftentimes what happens is like we get a medical device it's thrown on our network we can scan it with a vulnerability scanner but we don't get the full picture of what it's made out of that list of ingredients and so this is where an s bomb can really help us we can take an s-bomb before we buy the device in our purchasing process and then analyze it and say do we really want to continue with purchasing this if there's a risk that was found how can we mitigate it before implementing it

and so on so i'll join with one more thing there are organizations in the world that only use like six types of software right if you are just a traditional bog standard enterprise then s-bomb is gonna be nice for you but there's going to be public security advisories for your microsoft products your cisco products right those have mature product security teams and data about vulnerabilities and risks in those products is well documented and easy to access what we're talking about in the cavalry track is a very different world right it's the world of things that are literally matters of life and death those tend to be much smaller organizations that produce them and yes some of them are starting to do

vulnerability disclosure and security advisories but often the risk is not going to be this particular widget uh in part because they haven't they don't have security advisories and also because someone may not have developed a targeted attack for a foothold on that product the risk is sort of automated scanning tools that are going after some of the components and so that's why particularly in safety critical world medical infrastructure ics having that understanding is going to be important and the last thing is right it doesn't always feed into hey i need to patch this some of you are familiar with just how hard it is to patch something that if i unplug this people lose power people lose water

people die but what we can do is start thinking about it as more maturely of oh there's a potential risk here so uh my long-term plan is segment my network my long-term plan is work with my threat intel to sort of see if there's anything being disclosed so again it sets up the longer term risk especially in our cavalry mission space in a word it's all about transparency and it allows you to assign risk to the end user because somebody manufactured something here you manufactured this box or that particular projector or that wireless access point that's sitting over there we look at that and as engineers we go oh i know what that is and i can do a

physical attack on it tear it apart reverse engineer it all right but as a user what they don't know they're bringing this in and putting it into their environment and potentially affecting their environment their neighbors environment everybody's environment i mean we've seen a lot of denial of service here distributed denial of service attacks so it's actually more than just the 16 critical infrastructures the united states it's everybody we don't want another marybot type of episode again transferring that knowledge to the end user so they can say how much risk do i feel comfortable with right oh this has got a vulnerable version of openssl in here i can live with that i don't really care and some

people will other people will take it offline and pull it out so it is about disclosing all of that information not keeping it a secret moving it to the people who really are going to be affected by it and that isn't the people who manufactured it so about four years ago uh i was working with alan on another ntia project that had to do with updating firmware and how you patch and do upgrades of firmware and for devices in the field and we rolled off that and alan said hey i'm thinking about working on another project here that's called a software bill of materials i said oh what's that he says it's kind of like a list of

ingredients uh-huh of what goes into your products i went hey you know what are we going to do a month of that i mean that's going to be a short project that was four years later i hadn't a clue what all the edge conditions were that we looked at and in that period of time allen put together um multiple working groups that cover different aspects of software build materials but they all consisted of experts in the field and really humbling experts i mean i quickly realized just how ignorant i was of what this environment required and how to handle this and to this day i still find things that's like oh yeah i didn't think about it that way

that somebody else already thinks about great multidisciplinary group nobody nobody heard cats like allen all of these people are experts they're we're all egocentric a-holes all right and we all have our opinions and this man would manage to keep us going all in the intended direction and everybody working together uh you know if we spot that uh comet that's about to hit the earth and we need a team to mitigate that i want him leading it all right so it's been really interesting and very educational over this period of time and now recently allen moved from ntia to csa and where this new working groups have started up so ellen i've talked too much already

what what are your what's your feeling on the work groups both at ntia and csa first of all flattery gets you everywhere thank you um the and and this is actually what i love about what we built for the s bomb community right it's always very clear very much not my idea in fact since i joined government pretty much every idea i've stolen from the cavalry and said okay they start off with a great idea let's actually try to use uh the flag behind us to pull together communities to make it happen so i want to uh doff my hat to uh josh and bo and everyone who's been part of the cavalry i think

it's it's this is what it's supposed to do it's supposed to sort of take ideas mature them and then hand them to folks who can implement them so uh the first phase we have to do is actually come up with a shared definition the idea of an s bomb as chris said is is not that complicated but we need a couple things one we need a shared vision of what it looks like uh and no one had actually sort of articulated this is what an s-bomb is these are the boundary conditions and how to make it happen so the first years was focusing on the what the why and the how uh and there are the

good news is there was at least one data format that could transfer and to convey s-bomb in a standardized fashion the bad news is there was more than one uh and that's some fun that we still have is sort of managing the data formats uh we're gonna have a meet up in right after this if anyone wants to talk more about that so we're now at a stage or last year we would have staged where we have the basics there's no reason why an organization cannot start producing s-bombs asking for s-bombs thinking about how to use them our focus now is on operationalization scale and automation right if we can't do this if we can't integrate this data

into all the other things that we care about in security then we're not going to make the progress we need uh right my vision three four years from now is that we're actually not talking about s-bomb as a unique thing it should just be a standard part of our security ecosystem the same way that right most of us don't spend our days thinking about cves there is a small community that does but it's really we just integrate it into how we think about our security data so the plug for the work that's going forward uh if you'd like to get involved and i'll remind you at the end uh we've got a couple of uh focus points one is uh

cloud and sas a lot of the focus on s-bomb thus far has been on on-prem software which makes sense right i have to defend it it's on my network uh and certainly in our safety critical domain around the cavalry uh that's huge but i would and you guys can tell me if i'm wrong i think most medical devices now have a cloud management component right frequently yeah pretty quietly uh and same is true in ics the same is true in in a lot of other in automotive so we need to be able to tell a story of what does transparency mean for a sas application that may have a daily or hourly build uh and could be very large so we want to

tell stories of use cases and then ultimately implement it right so does the s-bomb of a container is it just the application logic is the application logic in the os is it the application the os and the orchestration we want to sort that out we want to do that with both producers and people who use that data defenders the second piece is going to be focusing on tooling how do we make sure that if two different suppliers or two different open source projects produce an s-bom they're reasonably similar uh and then we're going to talk a lot about consumption and the great tool that nyp has developed in a little bit we're also going to be focusing on

um moving this data around so how do we move all this metadata around especially the complex supply chain so it's got to go from you know an rtos vendor to a medical device manufacturer to a reseller to the hospital and then the last piece uh is going to be continuing some work that started ntia uh which we call the awareness and adoption group uh which was very ably run by audient josh uh and that is to sort of help think about one how do we make it easier and cheaper for organizations to uh engage in s-bomb and also how do we coordinate all the different things that are happening around the world so right now there's

some work that's happening at the international medical device regulatory forum one of chris's favorite organizations uh there is there's great work happening in all sorts of different corners of the ecosystem we want to make sure that there's a common hub to share information absolutely and when we started off i mean really the only person i'd ever heard talk about software billion tills before allen was josh and josh started this and he was sort of out there alone and we all went okay i don't know what that means and kind of ignored all that but in these working groups he really set the pace with crawl walk run uh and how we implement that and we have been

crawling for the last four years literally the we spent a number of weeks deciding how to spell s bomb i'm not kidding okay is it a lowercase or a you know uppercaseout all right there were things like that and we started at that level and now we have all these tools and techniques of how to apply this more importantly we've got an executive order that came in that now makes it not just little medical that's involved because they were the first ones into it but the 16 industries of that are critical to the infrastructure united states so now we have vendors and organizations that are looking at this saying oh yeah i need to supply you with an s bomb

we're moving from crawling we're into walking what is run look like and how do we get there that's what we're doing we're moving forward this is both an open source problem and a proprietary you've got tools from both sides and that's where we are right now we're right now and walking and trying to head toward that running so um i keep talking about medical because that's what i do is make medical equipment but there's a lot of other industries that are right behind us in some cases they might be ahead of us i mean automotive comes to mind they're very much into this and certainly it's not just the united states it's across the entire world countries like japan

and stuff are very interested in this and what are you guys seeing are you getting other interesting you know comments from other industries or i'm going to put it to all three of you or even from other hospitals besides new york press and what does this look like is there interested in adopting this and getting ahead of this ball uh i do think something that's interesting in the hospital field is we've seen some hospitals start by like when they negotiate new contracts with different vendors saying okay well when you provide us with a medical device we need you to provide us an s-bomb as well otherwise we won't sign this so that's one way that people are really

pushing s-bomb in healthcare money works money always works don't count on somebody's better nature if it's in their financial interest you'll have an s bomb the next day and then i think something interesting that's come from daggerboard is so we publish daggerboard it's open source and it's on github and we're seeing people that are wanting to contribute they're kind of interested and recently we were asked okay so how can the results from daggerboard integrate with an asset management system and that's something that we'll talk more on later but it's kind of an interesting idea that's really pushing us bomb further so the tools that have come out of this like daggerboard and we're seeing them

break up to it as we first got into this in ntia early on we realized we had to do authoring tools because it's a chicken and egg problem and we've got to start somewhere all right nobody was asking for this but then nobody could create one even if they were asking for it nobody could consume one nobody could distribute one so we're starting to see these tools now come out for the the two major formats spdx and cyclone dx that are used for uh software build materials and the tools are there we're starting to see more these pieces of the chain over its life cycle fall into play and and tools like daggerboard are definitely it and uh i

think that's good that we're seeing both commercial ones i hope they hang in there long enough to see success as well as open source ones like daggerboard and uh at this point we've been talking about daggerboard and why all this but uh adam and katie history of daggerboard where did this come from i when i think of open source my first thought is not a hospital uh so how did this how did this come about as the fact that you guys created one of the better tools out there yeah i think that we feel really lucky to be on a hospital information security team and have the opportunity to make this tool actually it was a lot of fun but

basically where we started was so arcizo he's a member of the healthcare working group proof of concept for s-bomb and based on some of the meetings that they had he came out with this idea that was hey uh we have the resources i think we want to make this tool that makes it easy to take an s-bomb and analyze it find all the vulnerabilities associated with it and report it so that the user really doesn't have to do that much because there wasn't anything out there that was like super freely available at the time so that's where the whole idea came from was let's make this easy to use and free and here we are now we actually managed

to make this app open source it and it's free something that was kind of interesting along the way was it's just like any other sort of open source project where we started really small we had the ability to do one thing like a script that analyzed s-bombs and now we have this project that's just grown a ton it can do a bunch of things um we'll see in a minute in a little bit like we're going to add more features have a version too uh and because it's open source we are always looking for people that want to contribute and work with us yeah and it started out as a beta project originally by the vulnerability

team and we linked up as the devops team just to make it revamp the ui make it easier for the analysts to use as a whole see all your vulnerabilities in one place all the packages in one place as well as making open source which was really one of the main goals for getting this app uh out there some of you folks i may have undersold what an s-bomb is you're thinking hey i've used three pieces of libraries and frameworks and operating systems in my product in my device that i've created why do i need tools like daggerboard and the answer is transitive dependencies are you all aware of log4j and what happened last december okay yeah i'm

getting a lot of head now it's good okay log4j is a very commonly used java library for implementing logging so you're sitting there at your day job and one of the requirements says oh my application has to have logging first thought that comes to your mind is log4j it's used by everybody in fact some 80 000 projects have used log4j so you reach out you include it when you include log4j you go hey that would be one of my elements in my software bill of materials and indeed it would but there are 294 sub dependencies in log4j that you as a developer have no clue you just brought into your product and with intentional corruption of these public

libraries skyrocketing last year it was 650 percent the year before that was 400 and some percent i don't know what it's going to be this year we just heard today about pi pi there were 10 libraries commonly used libraries in pi pi that have been intentionally corrupted to harvest credentials people are poisoning these repositories so if you have 294 of those sub-dependencies you can't do that manually that's why you need tools like daggerboard and other tools to go there and look at this and tell you what it is on a daily basis to come up and say oh this one's buried 17 levels deep and we found it here and it's we now have a

known vulnerability that's in this product so it is the only way it's where everything in cyber security is headed you've got to automate it all of this is becoming way too complex way too big for any person or group of people to do with a manual process so tools like daggerboard accent and with that let me stand out of the way and why don't you do a demo of daggerboard

i'll sit up here with ellen wow thank you thanks for keeping me company but yeah by the way uh we're originally under direct i was like where's your jacket i don't understand we had a whole plan didn't happen all right so let's go over you know what's important when we built this application so s bombs we need them all in one place but we need to start at the design level so and i don't want to bore you guys with the technical stuff but i'm going to go over pretty much how simple it was just to start the project and what features it had so first and foremost like we use the django framework just to start the application

to build the as a web application django is very friendly with it's very data driven very friendly with using data and you know using sbom data it worked in our favor so and mainly the main tool is to scan and parse the s-bombs and being able to scan based on spdx or cyclone dx another thing was to be able to integrate it within any application and that's where we had ldap and local authentication so you could implement in your your own and we have fancy charts and graphs all over the place so any analyst could look at all the all the graphs that are needed there and most importantly the open source that we made

it for open source purposes so our app doesn't generate s-bombs and we want to be clear with that um s-bombs should be provided by the manufacturer uh but if an s-bomb needs to be created from a manufacturer so if you're from a manufacturer um it's very easy to build and that we for for us whenever we need to build one we use sift which is a great tool and it's really easy it's just a one-liner um just you could connect it to your docker image or your requirements and produce all the s-bomb in any format in cyclone dx or spdx any format that's required so for daggerboard what are the important tags in this case for this

this is an example of an spdx document and the document name we use the document name the creator the organization the package name and the package version those are the four main tags that we use for all the analysis that we perform uh within the application yeah so in a minute we'll show like an actual demo of daggerboard all the data you see in daggerboard it's just coming from these tags mostly in an s-bomb file yeah and this is just a quick example of how easy it is to upload an s-bom within our tool pretty much you go to the upload choose the spd-x or cyclone dx document submit it and you are prompted and the analysis

begins it's all automated that way you don't have to go through an xml document and pick it out yourself so we we do all that for you yeah and again so this is like not really a live demo um we don't have internet right now but that's why we're showing a pre-recorded s-bomb upload yeah we're really worried about the demo gods um we don't know if our internet will work or not so we pre-recorded that and have a local instance for you guys so what's down the line what's on the road map um do you want to go over so before we get into the full-on demo um these are just our next steps for

daggerboard so the the next thing that we want to integrate is vect support this will give us the ability to reduce false positives we have in our data maybe for a given product it'll we can more reliably say these different s bombs contribute um so we should mention what vex is first off vex was a term that came out of the working groups was a term that came out of the working groups that absolutely everybody in the working group hated and still hate we hate this term it's a horrible term but what it stands for is vulnerability exploitability exchange and the way to think about it is it's extra information that is encoded in an

s-bomb and it's from the developer of the product to say a couple of things i'm investigating this vulnerability i've decided this product is not affected by this vulnerability or it is affected by this vulnerability and there's some couple sub states under there that lead with things like how it's configured so if you can figure it one way oh you plugged in ethernet into the rj45 jack yes you're vulnerable uh there's things like that that it's done in there very useful because there's estimates from 70 to 90 percent of unknown vulnerabilities can't be exploited as instanced in a product so vexes allow you to give you more clarity into it but it also gets back to

a level of trust so for me if i there's a company i think is good uh phillips phillips medical okay and i know they do good stuff i'm gonna trust their vex but if it's acme medical i almost said it really almost set a real company there so and i don't have that trust in them i'm not going to care what the vex says i'm going to unplug that device until i know what it really is so this starts to bring trust into the whole process and that's nothing we can encode in xml or json that's only something that can be had over years of experience with the developers who are doing this so vexes

are extremely useful it is a very much in a crawl form as we get into walk and run in the years ahead it'll be extremely productive and makes s-bombs even more valuable sorry for jumping in kit no no that was really good so the next feature that we want to add to daggerboard is an api right now you can upload an sbom and get results vulnerability results but what we need is the ability to have another system pull this data and say hey what's available and this can get us to our goal of integrating with asset management systems um maybe ci cd pipelines those are just a few examples we had in mind so our third uh

pro or item on our roadmap map is to add the ability to search for cves like chris had said earlier we all know about the log for j vulnerability from last winter right now within daggerboard you can find an s-bomb like based on the product's name and like based on what the s-bomb is but we can't globally search through all of our s-bombs that have been uploaded by for cves for packages so that's something that we think would be really helpful for the vulnerability analysis perspective and then finally the biggest thing a part of daggerboard was to get it open source get it put on github it currently is on github we have our link up here we

encourage you to take a look at it give it a try and if you want to contribute or discuss anything we're always open and so this brings us to our demo

all right so let's kick off the well let's get the beautiful login page that we we built here um so we need the icon of the so you're probably wondering what is the dagger board and it's basically used to keep the ship afloat so and to keep your company afloat you know you need to scan and analyze s-bombs you don't want any holes in your ship so that's what the representation of a dagger board is um so this is our login page let's log in and from we need to know from the perspective of an analyst what they want to look at so the two major uh things here are what are the most recent

s-bombs that were uploaded in this case you know and all the data here is not real this is all demo data from very old so there's no scrutiny on apache or anything else that you see here just as a disclaimer for you guys um so yeah we have the last two um s1's that were uploaded and the overall uh grade for that s bomb we calculate the grade um based on the vulnerability risk that's within um that we we pull from nvd national vulnerability database and along with their severities high low medium high in the middle section we have our highlights you can see how many total vulnerabilities were found within the application how many weekly the average vendor grade

amongst all the all the s bombs that were uploaded and at the bottom we have a little um we have a of all the we have a table of all the s bombs that were uploaded so moving on and we actually displayed this page during the the recorded demo this is where you would upload an s-bomb this takes us to our s-bom analysis page so what we can do is we can search for the s-bombs we've uploaded to go ahead and take a look and again like adam said we intentionally grabbed really old docker containers to show pretty charts and show a lot of vulnerabilities elasticsearch probably is not an s at this point this is very old um

but so once we've uploaded an s-bomb let's look at our results we can see here's the product uh we have a grade here we have the total vulnerabilities that were found an average cvss score and then we've got a beautiful spider chart based on the cvss vector and then a total of the vulnerability severities so scrolling to the bottom of the page we can see the packages that were found from the sbom file and so we can see we were able to find a cpe here and that's how we pull vulnerability data at this point now this is the part that i really like because i'm on the vulnerability management team i can go through here

and find more information about what vulnerabilities are present i could maybe search for something that's high i can maybe search for for a package and then most importantly one way that you may go through prioritizing your results is we want to know if an exploit's available so we can do that and we get an actual reference to exploit db we can sort by severity and then finally if we want to we can export a report of all the vulnerabilities that were found and view it beautiful csv and then moving on so we have a vendor analysis page and this is just a way to group the s-bombs together based on the creator tag so we have apache software

foundation here same sort of sorting if we wanted to view something else but we can see here we have five total s-bombs from apache they've got low grades total 80 vulnerabilities we can see a table here that shows when we uploaded these different s-bombs and then just the general distribution of vulnerabilities we get a snapshot of whatever was most recently uploaded so groovy was our last s-bomb and then uh just an overview these are the different s-bombs that we had from apache so now we'll move to the admin page yeah so if you want to deploy this in within your own environment or for your own organization uh you need to make it easier for your admins to configure do

certain configurations so we gave it the ability to for our back controls for your users you don't want some people you only want some readers to read the data versus people who could upload the data we also have the ldap configuration so you could sign in easier for your org you can manage your users we have a database we could basically create you can modify the database if you have to and as well as the grading you can modify the grading policy so it's not just fixed so based the criteria for calculating grades is very subjective um you might want to consider like if there is 10 if there's 10 high vulnerabilities what does that

mean to your organization and you could definitely configure that within the environment um and and that's about it um that's the admin portal and this is just one example of what we've been moving forward with on the s bomb initiative and we've it's come a long way as like a healthcare uh hospital and we're very like proud of ourselves and you know we're not really a tech giant we're a hospital so we've come a long way with buildings up and we're very happy with it yeah and i guess it just shows as part of the calvary track um that organizations like hospitals if you have the resources or you're willing to do this you totally can do it yeah so yeah

please visit our github and please contribute anyone and everyone's welcome to contribute to healthcare as a whole thank you i i want to flag one really cool thing about this build there are many really cool things about this project but one of them is there are a lot of security tools that just do one security mission but don't think about how it fits into an organization and i think the thing that struck me from this demo is oh yeah you we need admin tools we need to actually understand who's going to do what this organization figure how it fits into the broader mission and so i think that's a really cool feature uh that as we start thinking about more

open source tools that we can build instead of saying don't don't just do the the small thing figure out how you can integrate into the bigger picture so i think that's an uh thank you an interesting point too is that so when we started on this the daggerboard idea came from the healthcare aspirin proof of concept uh and initially in our first phase of daggerboard we decided okay this is only gonna be for medical devices let's keep it specific to healthcare but then as we got to our second version of the app we realized okay no this applies to every industry that works with s-bombs other people are working on it too we want daggerboards to be used by anyone

not just hospitals yeah and just the admin configurations alone i mean that was just that took a while to build and you know to understand how to map it and there's a lot of configurations that we did but to come at the end of this like it's basically this is just a starting point for this application um we're really looking to build this uh further and we definitely have a road map ahead for a little bit one of the things i took away from that presentation that's really important is it gives you the quality idea of your vendors the people you're buying from so maybe you've got uh you know that pdf viewer you put in your program from a large pdf

vendor who will remain unnamed but you all know that name starts with an a uh and you go you know these folks never give us patches they have nothing but vulnerabilities and all this the next time i'm going to create the next product maybe i'm going to go over and try some other competitors product and put that in there and so you're looking at this and you're doing continual improvement upon your product based upon not just availability and cost and form fit and function but also cyber security how good of a program did they have are they working with me are they a partner or are they part of the problem so i think a tool like that is

really useful to know remember we're all in this we're there isn't anybody who's outside of this we're somewhere in the supply chain that either we're sourcing it originally or we're building on top of it but i do have one question for katie and adam do you have an s bomb for daggerboard yes we absolutely do of course yeah [Music] it's published on that repo forever it's on github yeah and that's where it should be and that brings up an interesting topic which is some of the people you're now seeing complain about the fact that oh well if we give you our s-bomb we have to hide it behind a firewall credentials and the fact that you can't just get

access to it the proper place for s-bomb is publicly available in this case in the repo all right if you sit there and think that your intellectual property is going to be exposed by the third party software components that you use then it's not your intellectual property it belongs to the people who created the software components okay so so go ahead i want to show you the first i i agree that is the the awful place to do it um many of you know sunil yu an early leader in thinking about s-bomb and transparency uh he moved over to a company called uh jupiter one one of the first things he did was saying we want a

public s bomb and so jupiter one.com s bomb is their live s bond right it's a cloud-based product which means there are very frequent builds uh but so you get the live build but i also want to zoom out a little bit and talk about some of the cavalry mission which is it is our job to hold people's hands and walk them down the path for better security we can't just say right do security now and we'll beat you right nerd harder we haven't seen who says that doesn't work we haven't tried that approach but i think one of the there are companies that just have very natural aversions to sharing anything right there there's no okay

part of it is there's massive amounts of tech debt so they don't want to show that they have been shipping old stuff uh and part of it is just culture right so my lawyer says i shouldn't do this and i don't know or care enough i haven't talked to my customers enough customers enough to push back so one of the things that we've done is sort of try to push back on why it has to be secret uh there's a great myth busting document on the nti website that sort of pushes back against that but the other thing we can do is to say you don't want to make it public it's okay why don't you try to figure out

what access control at scale looks like for your thousands of customers and and yeah just you just need to make sure that all your customers have access to it uh in a timely fashion and it can integrate into all of your customers security tools and by the time you sort of they start to think about how complex it's going to be to engineer a way to share it safely they'll realize this is just a lot easier to share directly so there are ways that we can use some jiu-jitsu to get people uh to be more comfortable sharing at the end of the day you're moving around xml and json files this isn't exactly rocket science

uh there's lots of ways to do this there i mean obviously you could email them it doesn't scale okay nobody wants to see that you could put it on your website probably doesn't scale either it's a good first step you could actually set up your own servers and have those servers they're nothing but repos for s-bombs that's now getting into the place where you want to be there's commercial activities like uh archivist is one of them which one of my open seats whatever c3 whatever some of them that do distribution um there's even a a wasp project to establish a open api so all of these repos will have the same api restful api so you can just reach

out and automatically with programs like daggerboard once you indicate i have i want to fetch this one it constantly fetches and updates it and brings it in and uh so it's it is definitely moving into that walk run area where this can start to be really really useful so we talked about where we've been we talked about where we are what's next where are we going with s-bombs what do you guys want to see what do you think we're going to do alan what is sisa going to do with s-bombs now that we're here uh well what so as i mentioned the current status is where we're all able to sort of start moving this direction

the longer term vision is really integration and automation and that sort of means hey we've got to have interoperability those are fun challenges uh they're engineering challenges they're also business challenges uh policy challenges uh and and also massive opportunities so you know i i love that dagger board and hopefully you'll talk a little more about how you're gonna integrate this as an asset management because that's where we need to be going um i've talked about briefly these four work streams that cease is going to be mentioning uh the i'm going to start repeating an email address if you'd like to be involved and you're not on my mailing lists sbam sissa.dhs.gov what was that allen s-bomb

at cisa.dhs.gov uh just send me a note we'll we'll sign you up for these work streams uh and then of course the other fun thing is let's start building things and that's kind of uh where we're winding down here at this point but i do want to point out that what we need is more open sourcing we need more community involvement uh we this is a call to arms all of you need to get involved producing creating tools making s-bombs making them available this is a big project it's certainly not what i thought the first day alan started this okay it is a giant tidal wave that we all need to get behind and help what do we do for the cyber poor

who are out there how do we get them in a good place okay they need help there is a hospital that's in ohio well as a medical device manufacturer we always refer to hdos health delivery organizations like it's this monolithic thing they're all the same like they're all mayo clinic or new york presbyterian or or an organization that's large and doing things correctly they're not they're a spectrum so they go from that far extreme to this hospital in ohio where the same guy who mows their lawn sets up their network i'm not kidding this is the case and everything in between how do we help those people all of them they all matter especially those little guys they don't

have the resources the knowledge the funding to do this it's all incumbent upon us to put these tools out there get the information in front of them lower the bar so they can adopt this stuff think about this it's your responsibility these gentlemen started the ball rolling the rest of us are just rolling along with them and i'm including all of you in that as well too last words alan uber last i'm going to start with you first s bomb sissa.dhs.gov uh i don't have anything to promote besides check out our github but um just to touch on what chris said yeah i actually used to work for a hospital in kansas and we would buy a lot of those

small hospitals from rural kansas that were tiny and the first things that would happen after you bought these hospitals was they got hit with ransomware man what do we do now because no one can do anything and so um they didn't really have much i.t there and this is where s-bomb really helps us let's let's get s-bomb out there let's find out what's in these environments let's help these smaller hospitals figure this out adam yeah uh i i guess just contribute um contribute uh right now you know we have our day jobs and now that we've deployed something on on github as open source we have outsiders telling us to hey can you fix this can you fix that but we have

our day jobs we also need to you know work for the you know at new york presbyterian um so please help us out this is matters this is important we don't have any other way to do this when you look at those black boxes you don't know what's in them nobody does even the experts like myself i'd have to tear it apart and spend weeks on that one version to find out what's really in there a lot of work a lot of effort we need to lower the bar on this we have a huge installed base of really crappy products out there in the medical device industry we specialize in that we've got hospitals that have 30 year old components in it

all right 30 year old components how secure do you think those really are they're not we're looking at all of you think about this this matters this could save lives this will save lives as we go forward so whatever industry you're in make certain you're looking at this ask your vendors for s-bombs whatever you're writing even if it's a diary app that you're going to release you know out to the app store ask your vendors that you're using where's your s-bomb ask this keep that ball rolling keep it going i want to thank all of you for the gift of your time here today to listen to us and we hope to see you in our meetings

so obviously this is super valuable especially for the target rich cyber poor we discussed yesterday they may not be able to buy new things or hire new people but they can at least know what they're getting in these obsolete or older technologies and know am i affected where am i affected when the next log which they happen the bad news on some of these hospitals is now seven eight months later some of them still don't have a commitment on what's in the software when are they getting a patch so we're on a journey we're crawl walk running but this wasn't merely about s-bomb and the great work here i just want to look at these two developers

and the attitudes we keep hearing from thought leaders in cyber security that s bomb's too hard no one can do it no one can make use of it they say screw it let's just build something and part of this was a meta hint that i wonder if part of the next phase of the cavalry is we start teaming up with software developers open source contributors and that this is just one of maybe dozens of projects that could help waste water treatment could help oil and gas could help the target rich cyber poor and the food supply and i kind of like their attitudes i kind of like the contribution and i kind of like the idea that instead of just

just pointing out problems we might be able to create the tool chains that the private center is not yet willing to do this is a hint and a nudge not just to take s-bombs and maybe put the known exploited vulnerabilities list in it so they can target more specifically but also what tools could you ask for build or contribute to and advocate for so this is a hint maybe for the future of the cavalry we're going to be outside if you want to talk with us after this presentation if you've got any other questions right now if you don't want a voice in public right now it's a q a period questions

we don't have any portable mics i haven't i haven't been on the discussion list so have you been thinking about and i'm already well familiar with s problems josh may not recognize me but he'll know me in a minute um have you thought about when you're talking about cloud transparency other aspects that aren't just software components like does the software do sso integration you know does it support saml does it support oauth whatever do you do things like validating email addresses before subscribing people all that kind of behavioral stuff that's another level of operational information separate from what are the software components you use and i think it kind of like you said about tying it into

configuration management asset management tying it into information security policies at the organization that's building the software as a cso type role i get asked by people about the practices in our organization and everybody sends me a one-off questionnaire with 150 questions there's no standard for and i'd love to have a standard form that's s-bomb-like to give them to say here's the change management control practices we follow here's the software development lifecycle practices we follow et cetera et cetera so when you're buying this product from us this is what you're getting you want to chime in on the questionnaire they touched on one of my subjects okay this year the health sector coordinating council released the model contract

language mc squared 45 terms for hospitals to use in contracting with medical device suppliers and it talks all about the different cyber security expectations the most dysfunctional relationship ever is hospitals to medical device manufacturers always has been i've been doing this 50 years it's been horrible i'm trying to make it better i know a lot of other people are too it's kind of our goal we're starting with cyber security but this goes into a lot of different places so how do you do this so when you get those questionnaires mds squared of course obviously you're going to be filling that out obviously but the custom ones we're trying to minimize if we can get them to align to things

like this mc squared that will be a much quicker way to answer much less burden on the manufacturer in a much better position we'll all be in so on the idea of enhancing small i haven't seen a lot of discussion around specific security features although measurement of security features is one of my key passions which is how do i sort of quickly and cheaply determine security features where we are seeing a lot of attention especially from the cloud native world is saying in addition to my dependencies let me document my broader security process so let me have um right secure robust attestations of what compiler i used what my build chain was where i actually got the source from uh and

having each of those artifacts signed along the way the challenge is how do i meet how do we put enough semantic value into that data so that we can enforce it at policy level otherwise it just turns into right a paperwork exercise what we want to do and there are organizations including solarwinds today which is sort of saying here's the policy and we're not going to let code go to uh go live until it's checked all these boxes and one thing that the two major formats that we've influenced in ntia are cyclone dx and spdx they are both in motion and generally if one does something good the other one does something good and copies it i'd

argue that you go out i'm not going to tell you which one's better i have my opinions let you find your own but cyclone dx does have some of the stuff you're talking about in separate artifacts hopefully spdx will answer that and everybody will keep motion and we'll and we'll have ways to uh rosetta stone all that information together because that's where we need to be i think we've just got two minutes i'll be quick i have a really basic kind of s-bomb question i guess within policy is there anything in the executive order or anywhere else that kind of uh mandates uh the existence of s-bombs for federally funded software or products or that sort of thing that exists right now

where that's gonna be coming down the line legacy thank you yeah or well we're going forward either way so the executive order 14028 from 2021 uh mandates that everything the us government buys will ultimately have to have an s bomb that's going the mechanism is first it's going to be a memo from omb that's going to come out soon uh and ultimately is going to be part of the federal acquisition rules uh there's also some language in the draft ndaa uh the national defense authorization act uh that is going to apply to a couple different parts including a dod land happy to chat more about this and one last thing in medical device right now in senate is it's already out of the

house is the patch act i see somebody who knows this okay good uh what they added a writer on there that says not only is all the cyber security work needs to be done for release of the product and that includes s-bomb but also all the existing legacy product out in the field one more question can we do one more question one more question since we're taking up lunch great thanks um is it a reasonable step for medical device manufacturers to just put that in the mds2s like the s-bom details kind of as a as a baby step to having more of a live stream there are questions in the mds2 about if you have an sbom and all

that it's not a great place to do it uh it's not in a format that's easily machine readable so let's say i've got javascript is the basis of my device in some way phone i may have two three four ten thousand references doesn't really work in that you wanna stick to one of the markup languages json or xml that can be easily sourced consumed we're out of the days of emailing and texting each other to each other if i have to open up excel to pull something out of it ain't gonna happen right not gonna be scalable so flag that you've got one even point to the url where it can be fetched but now

um you want to come up we're going to be on the balcony the balcony overlooking the pool overlooking the uh fire pits uh to have a little meet up and i've got stickers who doesn't love stickers