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 go