
all right we're just about to get started with Alan Friedman's talk I'm going to introduce him one minute early so he gets the full time he's the director of cybersecurity at the National Telecommunications and Information Administration in the US Department of Commerce he coordinates NTIA x' work on cybersecurity focusing on building communities of passionate experts to address vulnerabilities across the software world he's going to give his talk you can submit questions to the SLI dot do and he will moderate those and answer those at the end of his talk Thanks thank you so much thank you everyone for joining us I'm a failed professor who got suckered into joining government about five years ago over the
last five years we've tried to tackle some of the fun and sticky issues in InfoSec where the government doesn't say we want this as a solution but there is a clear interest in having a solution out there and so we've tried to do is bring together the experts in the world who know about this stuff to say what will actually work for us so security is about unpredictability you're having a fine one afternoon and then all of a sudden Katz comes up to you no he doesn't say your basic blond dose he says we've discovered a new vulnerability right this happens all the time and sometimes it's in the top level software that you know about that's in
your vulnerability management system but more often than not it is going to be in a component that's gonna be a little under the water level it's gonna be used as a third party approach so do you have a chance to survive can you make your time I would argue that today there are very few organizations that can quickly and easily answer this question that can actually say when they learn about a new vulnerability in an open-source library whether you make software or use software there are very few organizations that can say we are affected or we're not affected and if we are affected here's what we can do and so our vision here is to actually tell
the story about how transparency can drive that resiliency that ability to say when we learn about these new risks we can adapt and respond properly so um transparency in the marketplace is not a new issue right we are used to a world with lists of ingredients and it's kind of crazy that we know more about what's in say a box of Twinkies then we do about what's in the software that's running our entire world and even by the way that's important fun fact those who didn't know this Twinkies not actually vegetarian now what's really important to remember is most of the time some of us may not care until there's someone in your life that's got a food sensitivity that has a
religious restriction that has a way of life and then it's very important that that data is available and accessible in a way that you can use it and that's the vision of transparency it's not about forcing particular behavior it's about empowering good risk based decisions based on your own needs and this isn't unique to the consumer space right so if you are in the chemical world there's something called a Safety Data Sheet you run a factory you get a palette of 50 gallon drums each of those is gonna come with a safety data sheet it's an ISO standard that says this is what's in the barrel and this is what you do when it up ends all over Frank so that you know
what to do with Frank when he's covered in the chemicals and even the term Bill of Materials comes from industry it's a very old term from the software supply chain er from the supply chain world which says if you go and buy a 10 ton diesel generator for your facility today right that's resiliency that's making sure you know what to do when the power goes out it will come with a bill of materials here's a list of every nut in every bolt so that you know what the total cost of ownership is so that you can do maintenance on it but today if you buy it it's going to be connected to the Internet and I would argue that
unfortunately today you have no idea whether that IP stack is made of the freshest healthiest ingredients or it's gonna do things that are damaging to you and yours so what why should we think about this for software well because I would argue for soft we're knowing what's under the hood is even more important and it's more opaque so here's a great project that a woman named a Saco son at NTT has done where she sort of said hey we have a single VAT manufacturer it's rebranded by a bunch of white box vendors how do you know what the firmware what the vulnerabilities in your IP camera are and these are not these aren't the cheap
ones these are the commercial grade cameras so this is you buy it comes from vendor you have to use a project like this before you can even find out whether there's a vulnerability hint there are several very real vulnerabilities in this exact camera one of which in fact was a key driver behind the mirror I bought in that attack that took down dime but of course software doesn't just run cameras doesn't just run organizations it runs large pieces of equipment and go boom and it runs small pieces of software that are about as important as that can be literally a matter of life and death so as we think about understanding the software supply chain it's important to remember that we
can wear different hats I like to wear hats and it can really transparency can drive real benefits based on if you make software you choose software or your operating software so if you're making software again first of all you've got to know what your ship this is something that surprisingly few organizations were doing even just a few years ago more of us are now aware of it but it's something that we're still trying to learn how to do better of monitoring for vulnerabilities but even just you look at what's under the hood in some of these large products there are some vendors that will ship a large product with four five six seven I've heard nine versions of the same piece of
software inside one blinking box that's used in critical infrastructure so it's not just about security we can tell a story about quality as well now if you're buying software seems to me that a very important question to ask is hey are you selling me something that out of the box will put me in my network at risk so this is something where we're going for where we're trying to say here are some of the questions that we can ask today or alternatively you can say hey your user giving me some software what do I know about it what don't I know about it so that I can do a more secure a more targeted security analysis and then
finally of course operating software I've got something on my network a new vulnerabilities announced am i affected is one of those core questions that we need to ask ourselves but almost as important is that last bullet which is if I'm affected and I'm waiting around for my vendor to respond if I know that I'm potentially at risk I can take risk-based decisions of my own I can tune my IDs I can segment my network I can take decisions that I think are the right level of precaution based on the software in question my network what's supposed etc etc so why aren't we doing this already right it sounds like a pretty good idea we do it in other areas
why aren't we doing it already well one answer is those pesky lawyers software licensing is a challenge until a few years ago I don't know how many of even the biggest companies in the world could honestly say that we know we've got all of our licenses sorted and we're not shipping any GPL products or anything like that I think that in 2020 that's a much better understood risk there are more and more tools on the market that can do this kind of analysis for you turnkey this is something that lawyers are aware of this is something that we have a better handle on today another reason is that it turns out it's actually a little
bit hard because for this to work for this to scale we have to have a shared vision across the entire ecosystem and we don't have that or didn't have that until recently and we didn't have it because it was a little bit of a chicken and egg problem right no one was asking for this information so no one was providing it no one was providing it soon known was asking for it so there were no tools to use it now that is what we economists like to call a market failure and market failures mean that your friends the government get to get involved right who doesn't love it when the government just shows up now how does the government
traditionally solve problems well we can either pay you to do things or beat you until you do it well and unfortunately no one gave me a budget or staff so I can't pay anyone to do anything and either unfortunately or fortunately Congress did not see fit to empower me to do jack so I can't tell anyone to do anything in any meaningful way so the solution that we have is we bring a bunch of people together and I say all go away if you all solve this problem and our vision here is act has been pretty ambitious because for this to work it has to apply across every vector if we go and say here's a solution for
the people who buy and build for DoD land and here's another solution for this regulated sector and Finance is going to go off and do it one way well that won't work because that won't scale and it means we won't get the benefits of tooling and mass adoption and we also have to look at the entire software lifecycle open source middleware commercial software embedded systems and perhaps most importantly the end customer so we're trying to make sure this is market driven we want all those perspectives at the table so we have this lovely thing that we call the multi-stakeholder process at NTIA and if you roll your eyes at the term multi-stakeholder process on the guy
who's to say it like eight times a day but it's the term that we're saddled with and so what we've done is we've tried to bring folks together just very quickly to assure any skeptics or people who are afraid what are we not doing it's not regulation again we're not empowered to do anything although I'll touch back on regulation a little bit later it's not source code disclosure it's not standards development we're not a standards development process and we're not trying to solve everything in supply chain supply the biggest big enough buzz word that you too can have your own federal government process based on whatever you want to do we're not trying to solve
everything we're looking at this one key area which is the thin narrow level of software transparency in a way that is lightweight and is meant to scale for all software we've been doing this for a little over a year I'm very pleased to see that a few of you in the audience lying I can't actually see anyone in the audience right now but some of you in the audience have been participating and I think we've made a lot of progress what have we done we have a shared vision of the scope of the problem we've developed some baseline definitions an emphasis on the fact that it's got to be automated it's got to have this broad
scope and on this handy-dandy website which is also going to be on some of these stickers that we'll give out you can see some of these resources we've sort of defined what is the nest bomb why we should ask them how do we ask bomb and then can we ask bomb today and we're still working on now the next step so very briefly Allen you've been talking about a nest bomb for a long time what the heck is it well here's a toy example of what it can look like I've got my Acme appliance and it uses two software components uses exactly two we know what they are and in turn Bob's browser we know uses carols compression
engine carols compression engine we know so the other thing in addition to having a tree here so we know what the relationships are which can go as deep as we want the other thing we're capturing is known unknowns so that when you look at this you have some idea of the completeness of information so we know that Acme appliance has exactly two dependencies we have no idea whether bingo buffer has any dependencies or not we know that carols compression engine has no dependencies it's a root in our tree or a leaf on our tree depending on which way you draw your treat believe it or not it took many weeks to figure out which way we should draw our tree to put
the root at the top or the bottom turns out as long as you need one way to do it standards are hard who knew so and we know that Bob's browser includes at least carols compression engine it may include more so you can look at this and get some idea not just what you have on your network but if you really need to know what's on your network you now know where to do further research or where to start asking questions so now each of those when I say here are the components what do we mean by a component I want to be able to sufficiently uniquely identify each component so what's the supplier what's the component name what version
is it right now I need to know whether it's up-to-date and then by the way give me the hash so that I can verify that you and I are talking about the same one I want to make sure that you didn't just go download some cloned backdoored copy on github so we've got our tree we've got our components how many levels deep to this tree go Alan as deep as possible we want as much information as we can but we also acknowledge that it's going to be hard to do at the beginning and so the minimum viable approach is you need to have at all of your top level includes tell me what they are and again
I say includes we're talking about third party code not the code that you write but what are the components that you're bringing on board and then ideally in a magical world if everyone does that we will recurse our way all the way up the supply chain and by the way if we're in an open source world then if someone really cares they can take on a lot of that ownership themselves so I've talked a little bit about the benefits but I want to flag to more systemic benefits that sort of capture some of the public policy interest here one is just thinking about how having this kind of transparency will help us when we do
discover something that's far up the supply chain so at the top here we have a traditional case of timed or mediation once we find a flaw which is I find a flaw we managed to convince the maintainer zuv that open source project and so they go and fix it takes them some time and then they put that patch out so the people who are using it say oh look there's a new version of this let's try to integrate that so it's got a cascade all the way down in what we might use the analogy here is a waterfall that waterfall is the best way to develop software right this is the analogy that we still love to run with
so in a world where we have transparency the software doesn't magically fix itself I don't want to overstate it but while you're waiting for that improvement for the fix to slowly percolate down you can be prepared you can make a decision again based on your risk and your needs to say we're going to put in something in line that will at least make us more comfortable thinking about our risks this so the other thing that I like is this is a real potential to have some changes in the open-source ecosystem itself where we can start to create some market driven pressure from downstream users to say hey let's think about what open source libraries we
should use and I don't want to pick on open source commercial is the same way which ones we want to use because now I know that my downstream customers and their customers have a chance to look at me and ask why certain decisions were made so a couple of great stories here I'm sure some of you heard the story of you have a choice between two projects one has never had any security issues whatsoever reported they've got no CDs the other in the last year had two public CVEs reported against them which one do you pick it depends as right answer but I would argue that having a CV against a software project is actually a good sign it means that
they are aware of security issues they're willing to fix them they know how to fix them and they're aware that fixing security issues involves a broader ecosystem initiative than just fixing their own code so I'm not going to delve too strongly to how do we do it I can just say that we've gotten pretty close to solving this approach we didn't want to invent a new standard the good news was at least one technical standard out there said hey we can capture s bomb data the bad news is that more than one technical standard out there said hey we can capture s bomb data so our vision was to make sure that we can reconcile
these two s P DX comes out a Linux Foundation it's a way of capturing open-source data it was built to address licensing issues but we can use it for our interest in security swig or software ID tags is an ISO standard that's great news if you work for a company that wants to trade around the world it's a little frustrating if you want to actually read the spec yourself and you don't have 390 Swiss francs handy but the good news is you can go online and look at mr. 80/60 which sort of details here's some of the spec years what are the fields that we should care about behind swig tags and again our vision here has been to make sure that
we can have bilingual translation and in fact there's a third standard called cyclone DX that's being developed in 200 ASP specifically for the online application needs so we also in the past year there was a proof-of-concept from the healthcare sector remember I said we're not regulatory I don't have any power but we've got friends with power and the Food and Drug Administration which regulates medical devices has publicly said we're going to require every new medical device that wants to come out of the market to have an S bomb well regulation got the attention of the healthcare sector and so they went off and said we can we're going to show that we can actually generate this today but
the medical device manufacturers can generate the data and hospitals including you know some of the best hospitals in America and your Vesey or sauna and Mayo Clinic were able to use that data against predefined risk-based use cases asset management vulnerability management pre-purchase risk decision-making that's the good news they were able do it the bad news is that without taking advantage of all the work that I've just described no one was able to do it in a completely automated fashion and so that's really where we're pivoting for for our next steps this process is ongoing we're continuing to refine and extend the model I'm going to talk to you about a few these challenges around namespace
but we're also trying to collect tooling this is not just open source I know that there are a number of companies out there today that are working to solve this exact problem for you that's great I'm from the Department of Commerce my agency believes in the power of people making money especially when they're providing a valuable good or service so that's what we're trying to do is capture as much of this as we can about what's out there today and then of course awareness and adoption that's where a lot of you come in how do we get this message out what are the benefits how can this help your corner of the security world and by the way would you
like to do a demonstration would you let you do a proof of concept we have a bunch of them ongoing this is your chance to roll up your sleeves and actually build something there are a few challenges were trying to tackle very briefly naming software is a known hard problem I would argue that in the history of IT over the last 40 years we've successfully solved the decentralized global name space problem exactly once and the annual budget of ICANN is about one hundred and forty million dollars so we're not gonna wreck recreate DNS but we can make some progress we're trying to figure out how do we do this in a way that is neither
centralized nor requires everyone to change what they're doing because that's easy right a lot of the solutions are oh this is super easy everyone just do what I do and then we'll all have the same model how do we share s bomb data this is again we need to make sure that it's getting into the hands of people who need it the vision here is not to say that there's one way to do it it's to say here's a small set of ways this problem can be solved pick one that works for you one of the core challenges that a lot of folks on them especially on the vendor side are aware of is they said hey just
because something's vulnerable doesn't mean that it's exploitable right I'm using open SSL ODOT 9 but guess what it's for a client-side piece of software so by definition it cannot be heartbleed able please turn off the blinking LED on your dashboard how do we allow that kind of communication to happen down the supply chain in a way that means that we can start to pay attention and focus on what's really important and of course I mentioned the opportunity for a proof of concept where since we have all this information out there today could you actually show that this could work for your organization or whether you build software or whether you're buying software or you know somewhere in the
middle what could it what could help you and what is the site motivation that you need so taking a step back transparency is part of the nutritious breakfast that is going to be addressing the entire issue of security in the supply chain right it's messy there's a lot of stuff there but transparency is going to be the foundation for thinking about it there are a lot of different solutions out there to improve on this but they all start with making sure that we know what's actually under the hood of our software so I have I think three minutes left for questions you can use your app I'm going to plea please get in touch with me that's my email address if you
send me a note saying you want to join I'll give you a sticker if you tweet with the hashtag s bum I'll give you a sticker if you ask the question I'll give you a sticker you come up to me and say hi I'll give you a sticker so let's see does s bomb scope include hardware and firmware so on firmware I would much rather debate which of our text editors is the superior in an objective fashion then talk about the difference between software and firmware what I will say is for firmware did you write it if you wrote it then it's your software it's not their party components if you're using third-party code in your firmware
then that's some that you probably need to be aware of and be able to track that hardware is a different problem in some ways it's easier especially at the sort of end of high-end chips in some ways it's a lot harder especially as you move down the supply chain into hardware because ASCII read a dim as a dim as a dim you're looking at it from manufacturer perspective you're saying this is just askew so we're trying to just focus on the software side of things so let's see I have a there's a question which is is an S bomb a tree or a directed acyclic graph that is a great question we will leave that as an exercise to the
reader so there's another great question which is hey couldn't some source code repository products like say github or bitbucket think about this and try to solve this for the entire ecosystem it's a phenomenal idea I've had the opportunity to work with a number of folks from github that are very interested in this github will do some of this for you today they will flag your dependencies that are risky so we're starting this the challenges of course while that gets us a lot of the way it doesn't get us all the way there especially when we're thinking about commercial software commercial software running on your network is sort of quite the black box side of things other
questions in the room before I I think I've hit the wrong button here there are questions the room you can just shout something out so that's that's a fantastic question the first proof of concept they decided for scoping reason they were only going to use the top-level dependencies as they've started to look into this especially for the art the art haces it's going to be big and in fact there are a couple of I know that someone has tried to write this for one flavor of a Linux kernel where they've activated will show yeah listen we found the way we as we compile it we can actually generate it so for the large pieces of software this is
gonna be very large and how many you got no I think it's a great question the I'm hazarding so I'd say on the order of 10,000 components for a modern operating system but again it's that's that order of magnitude if you want to know more about this scope the critical infrastructure initiative with Frank Nagel up at Harvard Business School just wrote a report of the first analysis of their attempt to do an open source census the data is heavily built or heavily sampled on the JavaScript universe because that's where the data was classic street light problem but that gets us some insight into what these dependency trees look like and where they overlap on getting the stop
sign so please don't hesitate to get in touch I'll be out in the hallway after this afternoon and I'll be around San Francisco all week so please get in touch and join us we need your help thank you [Applause]