Welcome to the Azure Security podcast, where we discuss topics relating to security, privacy, reliability and compliance on the Microsoft cloud platform.
Hey everybody, welcome to episode 69. This week it is myself, Michael with Mark, and we have a guest, Adrian D'Aulio, who's going to talk to us about S-bomb software bill of materials.
But before we get to Adrian, let's take a little wrap around the news. I'll kick things off.
I've got a few items I'd like to talk about. The first one is a colleague of mine, Andreas Walter, has written a blog post, which is the summary of 2022 security investments in Azure SQL and SQL Server 2022.
Nice succinct list, gives you a quick overview of some of the major changes that we've made in the SQL Server platform.
Next one is in public preview. This is actually another one of Andreas's little babies, is Microsoft Purview integration and access policies for SQL Server 2022.
This is actually really cool. You'll see over time that Microsoft will make more investments in Microsoft Purview, allowing you to set sort of global access policies and manage them in a sort of easier manner.
So it's nice to see this as available now in SQL Server 2022.
Still with a database bent, general availability. We now have encryption with customer managed keys for Azure Database for Postgres SQL Flexible Server.
You know, having mentioned this on numerous occasions, a lot of the big changes that you're going to see across so many Azure services is more support for customer managed keys.
Although I think we're probably getting to the end now, we're getting close. Use of AAD, Azure Active Directory for client authentication, as well as managed identities for client authentication, and also more support for private endpoints.
So it's great to see that Azure Database for Postgres SQL Flexible Server now has support for customer managed keys for encryption of data arrest.
Also in GA is Azure Active Directory authentication for Azure Database for MySQL Flexible Server. Again, like I just mentioned, it's these sort of big waves that we're seeing across the board.
And obviously the database products are getting that love as well. So Azure AAD or client authentication for Azure Database for MySQL.
Still talking about MySQL Flexible Server, we now have, again, in general availability Azure Database for MySQL Flexible Server now has data encryption with customer managed keys, just like Postgres SQL.
So again, as I've already mentioned, great to see more and more products giving customers support, customers control, I should say, over their keys.
And the last one, which has got absolutely nothing whatsoever directly to do with database products, we now have in GA, application security groups now have support within private endpoints.
So when private endpoints first came out, it didn't have things like user defined routes and network security groups.
Well, now, I think probably about a year ago now, that support was added.
Well, now we've sort of followed up with the next level, which is application security groups. Application security groups are essentially an extension of network security groups.
So again, it's really nice to see that private endpoints are getting sort of more of these network defenses. And that is all I have. Mark, over to you.
Yeah, so in my world, a couple things of interest. First is that a couple of the architecture design session modules, Module 1, the end-to-end architecture, and Module 3 are ready and pretty much can be scheduled for delivery for folks that do have unified support.
So that's been a big area of effort for me personally, getting these out there. There's somewhere in the 240 to 270 slide range for those two. So they are not small, but they cover the end-to-end view of security and principles and concepts and models and structured initiatives and how to deliver on those and reference plans on how to execute on modernizing your SOC and patching and backup and some of the end-to-end stuff.
The identity and the other ones are going to be coming along with Modules 2 and 4 and whatnot.
So that's something you can check out. The CISO workshop, that's sort of like our landing page for that right now. And of course the CISO workshop videos themselves, about four hours of recorded content is also there and available.
One thing I wanted to highlight, because this came up a few times on discussions on Twitter, I'm starting to sound like some of the old-school Microsoft people from 20 years ago, like where I'm starting to cite the immutable laws and the newer laws of cybersecurity risk more and more.
I'm going to pop a link to those into the show notes as well. We still see a lot of people kind of asking the same sort of FAQs in a way and saying, oh my gosh, it's a compromise. No, you're already admin. So it's not really a compromise if admin is already in the attacker's possession.
And so that's another sort of piece there. And then some news news is my next task is to work on the Microsoft Cybersecurity Reference Architecture, or MCRA as many people call it.
Effectively, that's one of the things I'm going to be focusing in on over the next few months. And so if you've got feedback or requests or, hey, we'd love to see something covered, feel free to ping me on LinkedIn or Twitter or one of the socials.
But yeah, we're also throwing the links for the MCRA and the videos for it there as well. So that's all I got this week.
By the way, for anyone out there who's not seen any of Mark's presentations, they're a work of art. They're actually a magnum opus. I mean, they're just huge.
No, they're so much better than my slides. I mean, I'm actually, I don't know if this is a good thing or anything I should be proud of, but my slides are like Times New Roman on white.
You know, I mean, that's basically it. But yours are actually kind of elegant and there's a lot of, I mean, they're incredibly dense as well.
I mean, you definitely take the award for the most content per slide that I've ever seen, but it's good stuff, you know.
I mean, so yeah, to anyone out there who's not seen Mark's work, you really should take a look at it.
And I'm not just saying this to sort of pep him up a little bit. He doesn't need any more of that from me, but the work is just magnificent.
And it's so broad and it's so deep and it's so insightful and it's just, and it's practical as well.
And that's one thing I love. I'm not a fan of sort of theoretical security. I much rather prefer security that's, you know, been there, done that,
learn from other customers, learn from ourselves, learn from our own environment and then sort of codify that into, you know, into material.
So yeah, I would highly recommend anyone take a look at those slides and the accompanying material.
And as for your comments about the immutable laws, I think you just called me old just then. Is that right?
I got gray hair too, my friend.
All right. So let's switch to our guest this week.
So as I mentioned at the beginning, our guest this week is Adrian Diglio, who's here to talk to us about Software Bill of Materials.
So Adrian, thank you so much for joining us this week.
We'd like to take a moment and just give our listeners a brief background on who you are.
Thanks for having me, Michael. Brief background on who I am.
I lead the secure software supply chain team inside Microsoft.
So I drive the central strategy for securing Microsoft's supply chain end to end.
That's entirely focused on protecting the developer and protecting the developer's engineering system.
Things like Azure DevOps and GitHub and the build system and release systems.
As part of securing the supply chain, SBOMs have been a part of our overall strategy.
And we've actually been involved in the SBOM space since 2019.
We were part of the CISQ Consortium for Information and Software Quality SBOM initiative,
where we were working on defining a new schema.
And we were there working on this since 2019, which was actually two years prior to the US Presidential Executive Order 14.028 that was issued in 2021.
The executive order is famous, of course, for mandating that SBOMs be provided for every piece of software sold to federal agencies.
So that ensuring Microsoft's adherence and conformance to the executive order requirements and preparing us to meet those requirements has been a large part of my role here at Microsoft.
OK, so I got to ask the like super basic question. What is an SBOM?
Physically, an SBOM is a single machine readable file. So it's usually JSON or text or YAML.
But it's a point in time snapshot that describes the various files and components that make up a specific version of software.
The analogy that's usually drawn is that an SBOM is similar to an ingredients list on food packaging.
So if you are allergic to something, you might want to be checking the ingredients list before you eat food.
In the software world, we didn't have the same equivalent. And so SBOMs are now a way to provide transparency into the open source components that developers use that's embedded inside the software that they build.
Gotcha. So it sounds like it's a fairly foundational component.
It's not like it's a solution like, oh, I just bought an XGR and it popped out alerts. It's like a foundational thing that other things would use.
Correct. And while the concept of SBOMs has been around for some time, they are really picking up steam just recently.
So I think the industry is still going through the crawl, walk, run motions of getting used to SBOMs and figuring out how to distribute them from producer to consumer and those sorts of things.
We want to live in a world where we have SBOMs for every single piece of software and every version of it.
Okay. So now I'm going to take a slightly snarky tone for just a moment, but I mean, that sounds like it's a lot of work. So why is it important? What are the use cases and scenarios that make this something I would want to invest in as an organization or as someone that's learning it or what have you?
So the benefits for a software producer. So there's two sides of benefits. There's benefits for the producer and benefits for consumers of software. For the producer, an SBOM provides you a baseline inventory of your dependencies that are deployed inside your application.
So it kind of automatically captures your dependencies for you. And that's a fantastic thing for for baselining. But the real benefit of SBOMs is the transparency that they provide to your customers.
And transparency is an element of trust. So by providing an SBOM, you are building trust with your customer base.
Additionally, the SBOM contains other metadata about the components that are listed inside of it. Things like unique software identification values and cryptographic hashes.
So because not all software is digitally signed, there are scenarios where you may want to rely on the hashes contained in the SBOM to validate the integrity of the software.
So it's another way to help improve the security of the the integrity of the software, or at least enable customers to validate it.
And then of course, there's the compliance with regulatory requirements.
The executive order is not the only thing that is asking vendors to produce SBOMs. There's the FDA, Food and Drug Administration.
All new medical devices need to be able to submit an SBOM to the FDA before they are reviewed and approved. And then medical device manufacturers need to submit the SBOM to the health care organizations afterward.
Furthermore, there's there's new policy coming out of the European Union. UN regulation number 155.
While this policy does not directly ask for something called an SBOM, it actually is concerning the approval of vehicles and the vulnerabilities of the components inside those vehicles.
And I've talked to a number of vehicle manufacturers already, and they all believe that an SBOM is the way to satisfy the requirements in that UN regulation number 155.
So it's gaining steam and adoption. Other countries around the world are watching closely to see how well this happens.
And so we're starting to see more and more countries follow suit with requesting SBOMs because they want to understand their supply chain risk.
They want to be able to answer the question, am I affected when the next log for J happens or spring for Shell?
And they were never able to answer those questions before. And with SBOMs, they can. They can know if they're affected and what is affected.
So there's there's numerous benefits on the consumer side, especially such as verifying that all the legal license compliance are there as well, because the SBOM lists, you know, what sort of open source dependencies you have and their license and their their version number.
And so these are all things that that enterprises out there want to be able to manage effectively according to their own policies.
All right. So following on from from Mark's comments, then your reply, you know, it's funny, I'm working with some customers, actually not not too long ago, who had no idea how prevalent open SSL was in their environment.
And there'd been a nasty vulnerability. And yeah, it was it was for some customers, pretty catastrophic and almost impossible to understand what their posture was, because they just didn't know where open SSL was being used.
And don't get me wrong, it's not just open SSL, it's many other products. As you mentioned before, this actually does sound a lot like a nutritional label.
I remember many years ago, there was an idea sort of thrown around about non SBOM, but a nutritional label for security engineering was what sort of engineering processes you went through.
And what sort of defenses do you put in the compiled on link code. So for example, stat protections and dress space layout randomization and the use of no execute those kinds of things.
I'm not sure that everyone anywhere but it's a similar idea but it's but it's definitely not SBOM. So just want to reiterate one thing, make sure I'm correct on this. So the big driver behind this is the executive order around supply chain.
Is that right? That's correct. That's, that's had the most push. Okay. And as early as June of this year 2023, critical software will need to be able to prove they are executive order compliant.
And by September 2023, all other software sold to the federal government needs to be able to prove that they are executive order compliant. And it's, it's at those timelines that any federal agency will be able to request artifacts of conformance, including an SBOM.
And so making them easily accessible is a goal of Microsoft's.
Yeah, so you bring up that point. So what is Microsoft doing? So let's say I'm a product within Microsoft. Pick on doesn't matter what the product is. What processes does that team have to go through? And then what is the results and where can people find that information?
So internal at Microsoft in the development workflow, our team created the SBOM generator that generates SPDX SBOMs. That's a software package data exchange. It's one of the common SBOM formats that's out there.
And it's also an ISO standard, which is why Microsoft chose to adopt SPDX.
And we created this tool that that outputted executive order compliant SBOMs and we integrated it into everybody's build pipelines across the company.
And so today, these SBOMs are generated at every build for all the production pipelines and some teams have already started blazing the trail for including the SBOM in their compiled bits.
So for PowerShell version 7.2 and newer and all accompanying modules, when you go install PowerShell on your machine, the SBOM is actually written to disk. The SBOM is included inside and that way it travels with the bits.
And it makes sense for binaries, but there's other types of software like container images and there's software as a service and cloud services where the consumer won't have access to the bits and won't be able to grab the SBOM.
So there are different SBOM delivery choices based on what type of software we're talking about. And we're working through that now.
Just to continue that PowerShell example, that's a good one. So you're saying that the SBOM is actually like a resource in the binary?
Correct. Yeah. So when you install it, it's in the folder, the directory.
So is it a separate file? Is it actually in the binary?
It's a separate file, yes.
Okay. And I assume that file is digitally signed, right?
We are working on that now.
Okay.
So yeah, PowerShell was a bit of a trailblazer because their customers were asking for it. So they went ahead and created the SBOM files and made them readily available.
And I have a link that maybe we could provide in the notes of this session to share with everyone.
Yeah, you bet. Okay. So I've installed PowerShell and there's a file in there that is the SBOM information.
Now what? What do I do? So if I'm a federal agency or just a corporation who wants to understand what the bill of materials looks like for a component, now what?
Does someone look at that? Are there tools that you run that say, hey, this component is out of this, you know, this part of this component is out of date or something like that?
How does that work?
That's a great question. The other side of this coin, you know, like step one is we need vendors everywhere to be generating SBOMs and making them available for consumption.
Step two is, you know, enterprises need to or IT shops need to have some sort of an SBOM management capability.
There are new tools popping up all over the place that do that where you can load in the SBOMs for your environment.
And then these tools do vulnerability lookups of all of the open source components that are listed inside those SBOMs.
So now consumers, not only do they know what components we're using, they can also look up and see if there's known vulnerabilities of these components.
And so Microsoft has has done some interoperability testing with with two of these vendors that make the such products.
So one of them is called SAG PM four and the other one is made by a company called Sybeats and the products called SBOM Studio.
You know, both of them are great. Both of them allow you to, you know, import these SBOMs and do vulnerability lookups accordingly.
Yeah, that's pretty cool. Right. I mean, it's all very well having the bill of materials.
Now what? Yeah, that's that's actually really, really cool. That's that's good to see.
So the other question is, you know, are we seeing this adoption industry wide?
Yeah, the executive order is the main driving force for the rollout of software bill of materials prior to the executive order.
And I think the whole reason why software bill of materials was included in the executive order is because of the work that the FDA was doing, asking for a software bill of materials for medical devices.
And when they were rolling out this new requirement, they were socializing that requirement with the industry for quite some time.
And the NTIA, National Telecommunications and Information Agency, got involved with the medical device industry and did two proof of concepts to prove out that software bill of materials are viable and useful and that they can be, you know, passed around and consumed with, you know, existing tools.
And and it's because of all that predecessor work that the request for SBOMS was actually included in the executive order.
I don't know that. That's actually pretty cool. That's actually pretty cool. I mean, as long as people can get hold of the SBOMS.
I mean, if I buy some software, how will I know where the SBOM is? Or do I expect a file to pop up in the folder during installation? Or can I get the SBOM before I even install the application? How does that kind of work?
You know, that may sway my decision as to whether I deploy this thing. If I find that, you know, it's got 27 known critical vulnerabilities in the package, perhaps I'm not going to install it.
Is that scenario possible or is it really, you know, are there defined processes around how to get the SBOM from any particular installation of a software package?
You bring up an excellent point. Everybody does expect that people will want to review an SBOM before choosing or selecting a given piece of software.
As such, the SBOM actually needs to be contained outside of the binary. It needs to be available separately so that it can be reviewed prior to acquisition of the software.
This kind of brings up kind of like an interesting point of where the industry is as a whole.
We want the SBOM to be included in the bits that get shipped to customers so that it always travels with the software.
But we also need to make it available out of band. Microsoft is currently considering ways where we would have like a repository of all of our SBOMs that you could search through and look through.
There's been ideas brought up about marketplaces and should they show the SBOM there prior to you choosing something from out of the marketplace.
There's a lot of opportunities and so there's a lot of cross coordination on figuring out what is the best experience that we need to have for our customers to make SBOMs like a first class citizen and, you know, natively support it in our work.
Yeah, thanks for that. I think, you know, just listening to all of this and knowing that the executive order is relatively new, relatively new event.
It's obvious that there's a lot of work going on here in the industry and it's great to see, you know, great to see Microsoft leading the way.
So why don't we bring this thing to a close? So Adrian, one thing we always ask our guests is if you had just one thought to leave our listeners with, what would it be?
Yeah, I just want to share that the tool that Microsoft created to generate SBOMs is now open source.
So you can go search for, you know, the Microsoft SBOM tool on GitHub and it is, you know, a general purpose cross platform, cross Windows, Linux and Mac,
build time SBOM generator that you can run in your CI workflows and it outputs SPDX SBOMs in JSON format.
So anybody can freely go use that today and start generating SBOMs for your software.
Yeah, that's great. I mean, I'm definitely going to take a look at it myself just out of interest more than more than anything else.
But this is but yeah, just go start kicking the tires on it.
So Adrian, thank you so much for joining us this week. I know you're a busy guy. This is an area that has certainly been of interest to me,
even though my knowledge of it is relatively small, but certainly my knowledge of it now is a lot better than it was at the beginning of the podcast.
So thank you very much. And to all our listeners out there, thank you so much for listening.
We hope you found this podcast of use. Stay safe and we'll see you next time.
Thank you.