 Yay, I'm here to rev you up after your sleepy lunch Your sleep inducing lunch Hello, everyone this talk welcome to this talk Where we talk about whether s-bomb for a cloud is even a thing You guys are special because you get the disclaimer that says I don't speak for My employer or the US government. These are my views And you get your large language model fix of the day This is something that I fed to Something called API because that's the one that didn't get asked me for my Asked me to create an account Just said okay. Go ahead and test it out and I asked it like If you are made of software and an s-bomb is a software bill of materials Shouldn't you have an s-bomb then and it helpfully replied? No, I am not distributed as a product So I'm just here to chat and help people out. Oh, that's so cute But everyone knows that large language models are trained on Things that people think so this actually reflects the way that Generally people think right now, which is Services are not distributed. So why does it need an s-bomb? Well In this talk, we shall explore what that means here Okay Little about me. I am the maintainer of an open-source project called turn Which is a container inventory tools it generates s-bombs for container images by the way, I have heard that this is the only Container s-bomb generator that fails closed rather than fail open Which is something that I found out from a talk that Ian coal water and friends Did at coupon so in the talk they showed that all the scanners that they were using for containers Said there are no CVEs Even there are no packages And they made it do that by like overriding some files. So But turn is the only one that goes like I don't know what this is. I'm sorry I can't give you any information. So Yeah, so I am the maintainer along with Rose judge Come talk to us about it. I'm also a contributor to SBDX projects I've written documents under like with in collaboration with CNCF stack security And I have been heavily involved in the sysa s-bomb working groups And that's what I'm gonna be talking about here today Justin Murphy has seen me in all of the working groups. Hi Justin And I used to be involved in the open container initiative Artifacts and reference like reference types work that you may have heard of if you were Listening to the keynotes this morning So I contributed I contributed to that a little bit But there's so much s-bomb work going on right now that I had to step away Okay, story time Some years ago 2021 was not a good year for software supply chain security stuff So in December 2020, there was the sunburst attack that got everyone all upset Somewhere around me Anyone who's involved in s-bomb may have remembered this whole string of letters and numbers Eo 14028 repeat after me No, don't so That's when the US government released their Executive order that said that all the suppliers have to give them an s-bomb Couple of months later there was They released documentation on what the minimum s-bomb elements look like so people can actually start Generating these s-bombs and then for a little while Nothing really happened and then all of a sudden in December a zero-day call log for shell Came out and then everyone started panicking all over again Somewhere in the middle People were running around trying to fix this. It's like there. There are companies that are still recovering from it Somewhere in the late fall of 2022 Sysa published that they had started off these S-bomb work streams which tackled different aspects about s-bomb and Earlier this year in April they had published some of their findings from each of those groups So these are the work streams that they created vexes the vulnerability exchange work which is talking about how to Communicate in a machine readable way how Whether a vulnerability is exploitable or not or what the status of the investigation is there's the sharing work stream which has Published the sharing life cycle report in April there's a tooling work stream that Kate's been involved in Kate Stewart SPDx Talking about the types of s-bombs based on the software development life cycle There's the and then there's two other working groups the under ups and adoption working Workstream and then the cloud and the online application work stream, which is the thing that this Talk is about Okay, while that was happening. We've had a lot of class we've had this class of Attacks that have been happening which basically involve Attack like phishing attacks on employees of Service providers and getting the keys to the service infrastructure and then exfiltrating customer data and so This is this class of attacks May or may not exploit a vulnerable component, but it is very much on the rise I'll talk about a couple of examples which are actually really cool to go through Let's see cue the What's the thing some music what the heist music from Oceans 11 or Yeah, anyway step one attacker fishes a dev Developer gets access to their laptop Searches for listens for credentials uses credentials to log into a dev cluster and exfiltrates infrastructure in for in internals systems information step two attacker Injects malware into senior DevOps engineers Laptop senior DevOps engineer has keys to the kingdom Attacker uses those keys to go to cloud backups Cloud backup data stores and exfiltrates all of the sensitive data What's Sad about last pass breach is that they didn't actually share that much about what exactly happened So We're still like Learning things about it. So it turns out that last pass does not encrypt all of the vault It only encrypts passwords Websites are still unencrypted and that was one of the things that was in the cloud Backups and when you have like website information about what the users are using they have the username and then they have the URL so you could create like a phishing attack where you say something like oh you've You are are you trying to link these two accounts or you've lost you verify this other account by clicking on this link So it's it's more the more information and an hacker has about a user The better they can craft a phishing email So that's the last pass breach. Let's look at one that is even more interesting Let's cue the mission impossible Okay step one Malware is injected into the engineers laptop Attacker listens for Listens for packets steals SSO session cookie Step two attacker uses SSO session cookie to authenticate themselves using Github's or odd service. Okay. Now they're in step three use Now that they are the engineer they can they have permissions to Exfiltrate data from their data store All the data is encrypted so step four you act the attacker the Engineer actually has permissions to create production tokens. So Step four spin up workload Exfiltrate encryption keys use encryption keys to decrypt data So this is like actually this is pretty cool sophisticated attack But the takeaway from these two attacks is that it's not one big thing that happens but it's a number of steps that Exploit like basic infrastructure sloppiness so this is it's it doesn't look easy, but Actually, it's using like very basic Attacks that can be automated with existing tools In order to take advantage of the fact that we do not know Anything about the configuration of these in of this infrastructure or even worse you do not know What the service is made up of like who are who what are the components of the service and that's why This is us very interested in the s-bomb for the cloud So there are three sub groups under the cloud and online application working groups The first one is s-bomb for modern applications. This one is a little weird because This is more like bridging the gap between folks who who have who are used to working on-prem and dealing with on-prem infrastructure and trying to get them to think about how Whatever in whatever knowledge they have maps on to services that are in the cloud So it's mostly about trying to find out. What's the difference like what applies what doesn't apply? the second one is service transparency, this is a subgroup that I lead and This is talking about Okay, let's not think about s-bomb for a moment and zoom out and instead think about Individual services that are talking to each other using an API So we're trying to figure out What is the minimum amount of data we need to describe all these services talking to each other and what kind of data? They're dealing with and the last one and this is like more of a vague thing Is called cloud stack transparency and this is more about how do we enumerate all of the all of the pieces of the cloud stack that a Application that you would be deploying on to the cloud would be interacting with so all the way down to the bare metal and This is still a work in progress. So I'm actually going to dig in a little deeper about How this conversation is going about? I'll start with our Consensus about how sass is different from on-prem software the way I think about it is like the difference between Someone owning a home and someone living in an apartment sure of our hands. How many of you own a home? Okay How many do the rest of you live in an apartment or? You know, okay So if you were to rent an apartment or rent a you know our own an apartment You are only responsible for the things that are in the apartment, but the whole apartment itself is Taking care of by like a super and So what that gives you is that you don't have to worry about things like You know if the power goes off in your apartment, but the power is there in all the other Apartments then you just call the super to fix it You know if your toilet won't flush Call the super if you're the there's no running water call the super If this is different from home ownership Full disclosure. I'm also a homeowner You have to think about all of those things now if you're if your toilet won't flush. That's your problem so The when you're dealing with on-prem software That's basically it you have full control of your whole stack But on the other hand you are also responsible for your whole stack. So the reason why folks move to Services or move their business logic to the cloud is because there are a lot of things that they just don't want to Deal with and they'd rather offshore it to someone else. So The the difference is that you You get convenience, but on the other hand you lose control From the security part of it if something happens on the on-prem In the on-prem environment Then it's restricted to that on-prem environment But if something happens in the cloud, there's like a whole lot of people that are affected along with it so it's almost like if the if the super turns like Breaks a does a breaker thing like the whole apartment goes out of power. Anyway, I've Extended that too much analogy too much So this is why I would like to introduce you to a concept called the shared responsibility model what this means is basically Getting folks to think about what responsibilities are on your end and what Responsibilities are on the service providers in and this includes cloud providers too. This is taken from the NIST publications and it's got like a It's real. I like I really like this diagram because it shows that there's a gradient of what is your Responsibility and what is the service providers responsibility? There are a couple of models out there that are Provided by Governments like this is the UK governments model You'll see that there are some that are clearly in The providers responsibility and some that are clearly in the customer's responsibility based on what kind of Service you're using and then there are some that are like grayed out This is a scissors Responsibility model as you can see it's like completely different It's there are there are more layers and different things are shaded And These are the shared responsibility models of each of the vendors. Obviously, they're all different So the takeaway is that this isn't standardized talk to your cloud provider for a shared Responsibility model if you are having if you have Business relationship with the service provider Ask your service provider for their cloud provider share and responsibility model So you get a better understanding of where the lines are so on that The cloud stack transparency subgroup works on tackling that shaded area Where there is actually a shared responsibility, but we don't really know where the line is so They are tackling this based on Function and so what they're doing is that they have divided the cloud stack into functional tiers. This is still a work in progress So I'll talk about how y'all can get involved in this discussion if you have ideas or if you want to Get involved and or just look around so They have divided each of the tiers into functions and for each function They are trying to figure out the minimum data set that is described that is required to describe this function Okay Let's move on to how Sass is similar to on-prem software. Well, the bottom line is it's still software. So It's still made up of things. There are still components providers Can be considered as suppliers and they can integrate into each other They still have dependencies. So that means that if you're using a service that service may be using another service So there's definitely a dependency graph there and there's still security concerns so Actually in the sass environment, this looks very much like Old-school bill of materials where you have business relationships and contracts with your suppliers So just replace suppliers with providers and you get a sass bomb so This is just describing what that might look like as an example. So this is Netflix's services And they use many different subcontractors they they have a good relationship with AWS So they use a lot of AWS services, but they also have their own services and They do use open-source components and they host them So it's the take away from this slide is that it's pretty complicated. So and all connected using Communication channels API calls Network connections, so they it is Useful for someone who has a business relationship not necessarily with Netflix because they're They're only care about end users. So this is like all of us. We don't really want next bomb but if they are Using another service then they would probably want this bill of materials of their services So to that effect we actually have come up with a Minimum list of data sets again work in progress This is a list of things that we had as a community agreed that We are able to actually provide data for this, but it's not the end all of it We're still looking for feedback Okay, let's talk about some use cases Where we can apply traditional less bomb sass bombs? cloud stack transparency things so The one of the driving use cases is am I affected by vulnerability X? so You find Vulnerability in the news and then you're worried and you're like, oh my goodness am I affected? Okay, in order to answer that let's look at a very basic Service provider they'll have an Usually you'll have a client that is talking to the service This client can be a web browser desktop app mobile app Command line to they'll make HTTP calls to the service So they'll make the calls to the API gateway if that client had the vulnerability That kind of falls under the traditional s bomb. So it's a physical. I mean, it's a Tangible thing that you can go and poke at an introspect. So That's not a problem and that's probably something that a service provider can give you now if the vulnerability is on the service provider side and in one of their Service software, this is a little tricky because You don't actually know Whether your network call is going to take advantage of that vulnerability It's very possible that that vulnerability is existing in the software, but it's Mitigated or it's not even used because the network calls just never touch it. So This is why Rather than Saying like okay, I want the s bomb for your control plane. You would ask, you know, hey, does my API gateway talk to Does your API gateway? Talk to that vulnerability or touch that vulnerability and you can say no So the second use case is am I affected by a service compromise, this is very this is something that is like very Common a common question that gets asked because a lot of times when you're talking when you're using a service That service may use some service other service to perform a certain function Very typical one is an identity provider. So the identity provider might be compromised But as someone who uses that service you may want to know whether the identity provider is You know something that the direct service may provide or whether they're offshoring it to Some other service so very much like a typical Bill of materials where you have contracts with suppliers. So suppliers are providers here The last use case and this is like a little tricky because it goes into GDPR territory And I don't really want to talk about that because I don't know anything about it Is who has access to my data? so when When you have many folks that are accessing the same service You want to make sure or you want to ask the question to the service provider that Whether there is an appropriate amount of isolation between your data and everybody else's data And in order to ask that question you probably want to know whether That service is using another service with data that is shared and so That's where like a SAS bomb along with the cloud star stack transparency work would help Because it could it could be within the same service the the same infrastructure even And that infrastructure is not very well isolated. So it's kind of like threat modeling But rather than sitting down in a room in a meeting room and having a conversation The service provider gives you a data sheet to start with and then you further ask questions based on that data sheet and And that's what we are trying to get to in these conversations that we're having with CISA This is Facilitating them Okay, can we generate this data today? Not really so Yes, you can generate s bombs for all of these Software components that are used in all of the services But they're not actually going to be useful because that's not what folks are Like that's not the critical part. That's not the thing that attackers are using to Get to sensitive data. It's actually configuration like misconfiguration is I Understand it is the second most common attack vector for services The first one is data breaches, but quite honestly the data breach happens because of a misconfiguration So and this is something that a top-level service provider is Responsible for clearly the rest of it components that they can use So they can set it up, but when they configure it, it's all on them And what happens is that if there's not enough isolation between customers then a misconfiguration From one customer will bring the whole house down So yes, we can generate s bombs for all the services, but they're not going to be useful but what is useful would is Actually some description of these Configurations and we don't have that right now And this is something that you know cloud is Trying to get a handle on but not really so We usually Cloud cloud developers usually talk about like over tools that can make your life easier But organizations that use the cloud have to think more deliberately about what exactly they want so the way that organizations Adopt cloud is that they start with what what their goals are so you start with the people You create you think about what processes you need In order to get to your goal You construct policy that hardens those processes you choose tools Based on the policy you create configurations for those tools based on the policy and then you go and run the tools and you have to do this repeatedly actually Kate Stewart had given a talk Yesterday it was the safety talk where you talked about how requirements are the ones that drive the implementation And if you do not know what the requirements are then you cannot create like Accurate bill of materials for what it is you can't create bill of materials for these kind of interactions and as a result you cannot enforce your policy so It's kind of like the the call to action is to take a step back and think about You know whether this is real whether this is really useful or not It's possible to create a spawns in services It may or may not be applicable Okay, so here are my takeaways for the talk if you don't want to look at all of my pretty diagrams Just look at this list of things That you may want to think about so As bomb for the cloud is kind of a thing We're trying to work on it not really as bomb is a really funny word to use for this It's really more of an actual bomb But even bomb is not a good word for it. I particularly like data sheet But nobody that I talked to likes data sheets, so I don't know maybe I'll make it a trend over here Please use data sheet I Customers definitely want better service and cloud stack transparency so service providers Can't use that whole thing that we are not distributed. We're not distributed So I won't give you an S bomb. They can't use that because Customers will ask for it Um If you're using a cloud provider ask your cloud cloud provider for their shared responsibility model Full disclosure. I work for a cloud provider not a very famous one, but getting there. I hope They have a shared responsibility model if you want to use Oracle cloud infrastructure You can search for the shared responsibility model online. You'll know I think I Personally think it's pretty good In in so far as explaining where your responsibilities are based on what you use But yeah, that that's a place to start asking questions You can apply S bombs to any software that you distribute It's not like service providers cannot generate S bombs for you But it is touch and go and whether that would actually be useful for you You'd gain any information that will help you from that my opinion here is that You need more refined Information other than the S bomb so few more steps to go there You can apply Sass bomb Sass is not like really a word. I like either but I I'm very bad at naming things I'll cloud I'll crowdsource some ideas. So a service bill of materials if you will You can I play that for hosted services and we're working on a white paper that explains how to do that Vex usage becomes really crucial for services Simply because we don't have the tools to give any kind of refined information. We just don't Even right now traceability and observability is a thing that we're still talking about because we can't You know get a full idea of what happens in the cloud so Vex usage becomes really crucial just so you can say like yeah, we're investigating this vulnerability or no It's not exploitable or you don't you don't even see it in the service that you use Etc. So Vex becomes really important there as Bombs for the back-end clouds infrastructure It's not a thing yet But you can help create that because you can get involved in all of these working groups here These slides are published on the talk website so you can download them I hope the links work if they don't work. Let me know. I'll put my Information in the next slide. It's the next slide Alan Friedman from CISA Kindly reminded me to put the s-bomb at scissor.dhs.gov If you want to join any of the CISA working groups just send an email there and they'll get you all set up Each of these links are to the meeting notes and the white papers that the group is working on and That's the end of my talk. Thank you so much for joining in at this very nice sleepy hour It is a very sleepy hour you can reach me on all of those social media thingies Special thanks to Alan Friedman, Bargav Vivekanan and Ricardo who's here somewhere. Maybe not. Okay So, yeah, that's the end of my talk. So it's time for Q&A. I've left a lot of room for Q&A So you can ask me any question. Yes. Go ahead. Oh When when considering for s-bombs for these cloud providers have What is the expectation that they'll actually be able to give these so a lot of the cloud providers? I've talked to they consider their That's everything underneath the hood is their secret sauce proprietary. They don't really want to discuss it or acknowledge it So how do you see some of these working groups moving forward to address that proprietary? Yeah, so They they are not obligated to share their proprietary secret sauce, but they do have public API's And and they have documentation on those API's Anybody can look at how to use those API's there are hundreds of YouTube videos out there Showing you how to use the API's and what client tools are there? typically the client tools are open-sourced even though the Even though the services in the back end are not So Yes, I understand the fact that they probably cannot provide a full s-bomb for the services they host But they can certainly provide an s-bomb for like a top-level service So for example, if there's a storage service that we are offering Then we can provide We can provide metadata for that service so we can say like yes This service is a storage service that uses HTTPS with authentication You can But they can't provide any information about what kind of data you're going to use because that's the that's your That's your side of the equation So you decide what data you want to store in that storage service There's there's nothing. I mean and that's all you need, right? You What good is an s-bomb in that situation? I Mean it's a question that I'm asking maybe you all have an answer to that Can you pass the mic over there you got me thinking thank you Good talk. I'm wondering realistically. We don't have build materials here. We have bills of services So bosses, can we go for bosses now? Let's call it a boss A boss has in it is What you have actually have that ability to have access to Yep Potentially references to other bosses So That's actually what the service transparency working group is working on like what what are the data types that describe a boss So kind of a related question So you have services that use other services that use other it kind of reminds me of software that has dependency on other software So if there's like a vulnerability way down here, do you envision the bosses being linked like we have links and dependencies and software? No Yeah, we actually talked about that like You know dependencies of dependencies and how deep we want to go and What the result we came up with was that there is no way of validating whether that's true or not You can only go as far as you know, the the one level down Which yes, so that's that's what we do anyway is Is Like even even in the regular like I come from manufacturing. So I think about electronic bill of materials too and the way that like reliability engineering works in that field is that you You have a problem with one of the components that you know of and then you contact the supplier of that component You don't know what's in it. You just tell the supplier. Hey this thing broke That supplier will take their component that same component do some analysis on it and say, oh, yeah, this capacitor blew up Who's the supplier of this capacitor? I'm gonna go and contact that guy. So You as like the electronics You know the consumer electronic holder Don't know anything about that and you don't care You just want to you just want to know like, you know Whether this is something that you need to worry about whether there's gonna be a recall How much of money you're gonna Waste on this so it's very similar to that. I think he has a hand up So it sounds like you're describing I'm a consumer. I receive my application from from a vendor who I've paid for it from It comes with my S-bomb that tells me all the random little components that are inside it And really it also comes with another bill of materials, which is every network connection that comes out of this application Some of them are what we think of a service is some are back to that vendor for you know a soft service Some are hitting the internet for a public thing. So it was almost like it is a Bill of network expectations And yeah, so it's the connectivity part and the You can never see beyond the connectivity endpoint. So you're just like I I get a page from Wikipedia It will be pulled into this application and shown Therefore there was a HTTPS Wikipedia node in the connectivity list. So that kind of feels like where this is going So is that called a Benny? Bill of end Network endpoints Look at that. We're coming up with all kinds of nice like media savvy hype names Anyone have any other questions about this any concerns this Is this overly scary? Oh, there we go. Get it any plans for standardizing the format for these services S-bombs No Why are you making me step in this puddle? There can be more than one standard as long as As long as folks are you know As long as folks Understand what the use case is for this? I am personally happy because In the end what we really want is Not not full transparency, but at least some level of transparency So we know what we're dealing with and we can make you know good decisions based on that So for example, I would I would really like to know if you know a service. I'm paying for as an individual is using You know is using and third-party identity provider. So if I was going to use You know a health care service to That the doctor is providing I don't know zoom care Maybe zoom care uses octa for their identity provider and octa. There was actually a data breach I would like to know if zoom care is using octa. I'm sorry zoom care. I'm just Using you as an example. I really don't know whether you're using octa or not. Sorry. I Would like to know though. Well before my question Just shout out because Gary is organizing the spdx profile meetings to try to explore capturing this into spdx at some point So I haven't been a like to those meetings I've been I've attended some but I feel some of the discussion there is Clouded By the fact that sometimes it's a relationship between a consumer Who is using a proprietary service, which is opaque? But if you think about it and you move it let's say internal customers inside or for an organizations where visibility is not a problem You would necessarily want to have that link of service to Esbom to the components of software and Oh, I think we're okay Okay, and So But it is a reality that sometimes you will need to want that information from the outside So is the working group tackling that problem of? As an internal person in our organization I want to understand if a particular request hit endpoints or affected services while at the same time consumers outside being able to At least content address the same information without having visibility into that Yeah, so let me see if I can summarize it. You're asking whether like service providers themselves can make use of like the S-bomb and the service stuff or Okay So let's say I have a service and it hits two microservices and As time passes I want to know which requests were served by a component which was affected in some way Internally, I could have like a lake of data with all of those S-bombs. I can go relate the information and it's fine but when I'm outside I need to have a way as a consumer to Get the exact Diagnostics without knowing the details and it this is some somehow related on there were jokes about I want to know the S-bomb for Microsoft office for example But if they don't want to like share the details, can I still address some of the internals without knowing them? That's up to the service provider unfortunately, so if they want to expose That data to you and and sometimes they do like they do have You know the ability for you to have like metrics And observability stuff like you can instrument your services if you want to But that's only up to the platform that they provide, right? So for example If you if you were using a Kubernetes cluster Or you were you using like I'm sorry go back if you were you using the cloud providers Kubernetes offering so for example Eks And you were deploying containers into that They have no problems with you instrumenting your containers and your Cluster and they probably provide some kind of instrumentation from the Kubernetes side But anything below that they probably will not share with you so for example if Kubernetes is running on some virtualized Virtualized substrate, I'm calling it a substrate If it's a virtualized plane That Kubernetes is running on you probably will not get any information about that virtualized plane you'll get information about the Kubernetes cluster, but Not not any nothing below that and that is determined by the shared responsibility model. So if you Yeah, so if the if the responsibility is on the the cloud provider side They're like no no don't worry about it. We'll take care of it And we'll let you know like if something goes wrong or not trust us My question exactly is how do you trust the data that's in the S-bomb? Where are you storing it like if I'm the consumer and I'm like I want to know what's in Microsoft Office? And I get this table of data. How do I trust that that's up to date? And yeah, how do I verify that? This is my favorite topic I can go on and on about it. My answer to it is how do you trust anything? I Mean this is this is something that is funny about like the whole Question of you know, can I trust this S-bomb and I'm going like well You're like all your services are based on demos that other people have done and put on YouTube So I don't know you trust that But yeah So hopefully not because S-bombs usually have Like verifying data with it And actually spdx 3.0 has added some new functionality about verifying Usage as far as like checking whether the S-bomb itself is tampered with That's like an external verification step that you have to do. So maybe there's a S-bomb that is stored along with hash Actually, this is one of the things that This is why I was advocating for storing S-bombs in container registries because container registries use Merkel DAGs to Check for integrity of each of the components that make up a container image You can use the same thing for S-bombs or any other artifact for that matter It actually provides integrity checking out of the box And then there are tools like cosine that use six store to sign any art you can sign any artifact with cosine and Adds the digital signature to the container registry. So that That stuff would be really cool to start using but Other than that like I don't know like you got to trust something I'm sorry this. This is the last question because we have the next speaker Awesome. Thank you so much for coming add link to And go back to bed