Podcast Transcript

Introduction:
You're listening to the RSA conference podcast, where the world talks security.


Kacy Zurkus:
Hello listeners. And thank you for tuning in. We have a great podcast lined up for you today here at RSAC and we'll be discussing protecting data and the supply chain with my guests, Edna Conway, and Diana Kelly. Here at RSAC we host podcast twice a month, and I encourage you to subscribe rate and review us on your preferred podcast app so that you can be notified when new tracks are posted. And now it's my pleasure to ask both Edna and Diana to take a moment to introduce themselves so that we can dive into today's topic. Edna, let's start with you.


Edna Conway:
Well, thank you. It's certainly my privilege to be here and I'm lucky enough to serve as a VP of security risk and compliance for the life cycle of Microsoft's Intelligent Cloud infrastructure. And let me just add a bit of clarity about that one. When I say security, what? So, secure for me means ensuring the integrity of every operation, transaction and workflow across our cloud ecosystem to deliver the productivity that our customers expect free of compromise. And when I talk about resilience, what I mean is including proactively monitoring and preparing for disruption, which is a great topic for us given the year in which we find ourselves Kacy, so that continuous quality service can be delivered.


Diana Kelley:
Hi, Kacy, and hi, everybody. Great to be here today. Diana Kelly, I am the CTO and co-founder at security curve. I do V CSO and advisory work, and I have been in IT for well over 30 years now, which is crazy, but certainly seeing a lot in terms of what's changed in the need for supply chain and how important it's become as we build and secure our ecosystems.


Kacy Zurkus:
It is an absolute pleasure to have both of you here with us today. And I'm fortunate to do a lot of work with both of you because you are both members of our program committee as well. And you two are the chairs of the protecting data and supply chain track. So, very much looking forward to what you've selected for us for our June conference. But today I want to start by asking each of you... We talk about supply chain. We talk about this life cycle and protecting governance, but what do we mean when we talk about supply chain? What does that mean for you? Let's start with Edna and then Diana.


Edna Conway:
There should be a similar answer from everyone, but as somebody who's been working on security and risk management in the supply chain for the last 35 years, I am always amazed that there are divergent answers to this. So I'll give you mine, which I think is pretty uniformly adopted. It really means the end to end life cycle of a service, a solution or a product. So, it really starts with that first crazy idea that somebody might have, then you do some research and experimentation, and then it moves on to how you design and how you actually plan and how you actually go out and get what you need to deliver that service or solution and make it, or develop it or do both and how you deliver it, how you sustain it and what happens after it is end of life, end of service.


Edna Conway:
And hopefully if it has tangible elements to it, reborn and reused, given our commitment to environmental sustainability. So, just think about the old days you would say from cradle to grave, that was always used with a tangible product, Kacy but you can use the same model with a solution or a service or software. And I think I always remind everybody, here's the easiest way to remember what a supply chain is. Nobody delivers a capability or a solution, or makes anything from nothing. There's always a global interconnected ecosystem that every human being, every enterprise, every community and government relies on. And boy, if you did not know how important supply chain was before you surely do know today, as every aspect of our lives has been upended by the impacts of the pandemic on our global supply chain.


Kacy Zurkus:
It's almost a hustled term now. Supply chain, who doesn't know, who isn't familiar with that. But Diana, go ahead.


Diana Kelley:
Thank you. I was just going to say, I love what Edna was saying about making sure that we look at this as cradle to grave, but very simply supply chain is the stuff that goes into the stuff we buy, including how we get to the things that we buy. And as we talked about supply chain in the past couple of years has been really upended and partly for many different reasons. First, everybody was just buying a bunch of toilets paper in the United States, we weren't sure why, but everybody was buying toilet paper at fear. We wouldn't be able to get it. Then we couldn't get certain things because the packages that shampoo was going into couldn't be manufactured quickly enough because there were outages at the plants.


Diana Kelley:
And then we look at what we're facing now with there are issues with stocking the shelves again, and it's because so many people are out sick. So, there are different reasons that supply chain disrupts. And very often when you talk to companies, the executives may look at supply chain as the widgets we need to build the widgets that we sell. So, if they're not widget, sellers and widget can be any physical thing, they may think, well, we don't have our own supply chain, but as Edna was pointing out, supply chain is really about anything that we're buying. So, it sure it could mean laptops. It could be physical things that we're buying, or we are creating if we're an auto manufacturer, for example, but it's also those services and software. And that's where we've seen a big switch in focus and understanding of how important it is. The software you buy and the software dependencies of that software, that your vendor supplies to you that can matter.


Diana Kelley:
As we saw recently with Log4j for example, the services that you buy from your partners and who they partner with their own suppliers. So, you're fourth party suppliers and fifth party that can matter to you and your security and your overall resiliency stance. So, supply chain is really, it's very large and encompassing, and it really impacts every organization, whether you know it or not. And I think as Edna was pointing out a lot more companies realize that they haven't now, but it really goes well beyond just we don't make widget. So, it doesn't matter if our sub widgets aren't available. It's about the stuff that you run your company with, the partners that you do business with and making sure that you understand all of their dependencies and risks too.


Edna Conway:
You said something that's really important. Which is, it's about everything. I think there's something folks forget. And we've certainly thought out thinking about, I use Diana's word widget, and then we moved to services. So, if you think about, for example, the cloud service, you are tapping into whatever that cloud service uses to deliver that capability to you. I'm going to offer another thought that I think our eyes are opening to because we've been talking. And I know Diana and I have been talking about this. I've had the privilege of talking together with her for years now, about digitization. And a lot of people have worried about what does that mean for the human interaction and the human participation. Let's remember people are actually one of the most fundamental parts of the supply chain. You just heard Diana point out. You can't wash your hair because somebody is in the plant that makes the plastic, that gets molded into the container that your shampoo comes in. So, guess what's at the core of that. It's called us, the people. Never let that be forgotten.


Kacy Zurkus:
I think that's so important. And I remember months ago when we were going through all of the submissions for this track, I remember asking each of you, what do we mean by supply chain? Are we talking about supply chain, toilet paper and shampoo, or are we talking about the software supply chain? And I love that you've outlined those distinctions, but also the commonalities there. I would love if you could speak to our listeners about how to inventory and understand your immediate software supply chain dependencies. Diana, do you want to start this one off?


Diana Kelley:
Yeah. And this one I think is weighing on a lot of people now, too, because of the introduction of the SBOM, the software bill of materials, which is something that was long overdue. For very long, we would buy software either off the shelf from a commercial supplier, or we would work with a company that was building the software for us, but we saw it as a monolith. I'm buying the software, you give me the software and I don't really know what the different components are, but there are different components, especially nowadays where it's very rare to find software, even from a large commercial vendor where every component and every feature from the ground up was written by that vendor. We use libraries, we reuse functions from other companies, other developers, and that's not a bad thing it actually allows us to go much faster as we build more and more software more quickly.


Diana Kelley:
But it does mean that we have, as you just said, Kacy we have to understand what's in it. So, the inventory start at the very top. What software do you have? And that's as simple as what products do have, what licenses do I have, what cloud services and software as a service am I using out in the cloud. And then to get to that next level, to truly understand the nested dependencies within that software, talk to the providers of the software. If they have an SBOM or Software Bill of Materials, that's great.


Diana Kelley:
That means that they have already identified all of the dependencies for you. So, you can keep an inventory of that. If they don't have it, then talk to them about what really goes into making that software, what the dependencies are, what libraries they're using, for example, what other features functions they may be pulling in. The APIs that they're connecting into in order to make their whole solution so that you can then add that to your inventory. So, definitely start at that top level, and it'll give you some view across what you're using at the organization, but don't forget that top level isn't telling the whole story. So, you want to get down to that next level and if your vendor has an up to date SBOM for you all the better.


Edna Conway:
Yeah. I think that's a great way of describing it, Diana. We're all really well familiar with build systems and capturing our development of code in a dedicated build environment in the best those environments allow for digital code signing and release notes and bug tracking and search and then you take it out and do that. But what we haven't been perfect at is exactly what Diana articulated, which is meticulously identifying all the third party code that is incorporated into our own. And then lifting up the cover and saying, if you think about when you buy food. You know the out fundamental elements of what you are buying, but you may have an allergy, therefore you need to now know the ingredients.


Edna Conway:
Do you go one level below and say, I wonder who makes that? Because there is one particular company that I have of a tremendous adverse reaction to, and there are two others that I don't. That's where we're going with the concept of inventorying and tracking your third party software supply chain. I do think as developers continuously integrate a broader set of code, we really need real time tracking so we can more swiftly identify the vulnerabilities that may be deeply embedded into our own code. But I want to remind everybody, we need to do this for reasons other than just security. It's why I keep saying, we need to blend security and resiliency together. How about just plain old fashioned quality?


Edna Conway:
Where do you find the third party that forgot to sign the code and you want to go check something or you've done pen testing. And that pen testing reveals something that may not necessarily be directly related to security, but it's a gap in connection that is going to cause a failure in the expectation of the software user. You'd like to go talk with them and check on something. You need to know who that is, what they did, where they did it and where you put it, to evaluate whether or not that's an issue. So for me, generating build manifests is an essential element of capturing the key field. We need to know to make what we actually will talk about when we get into the details of an SBOM.


Edna Conway:
And I guess I'd put in a pitch as well for you said, how do inventory and track collaborative hub for real time multiparty code development have been around for a while and they can be an effect tool to assist again, right back to understanding who owns the hub, who contributes to the hub and what the hub does to ensure the integrity and security practices of itself and its users.


Diana Kelley:
Yeah, that's a great point. Also, companies that may have gone down the software composition analysis Or SCA route, especially if they were looking at, they had a lot of libraries, open source libraries and use, they wanted to make sure that they were on the most up to date versions. They've got a little bit of a leg up because they've been tracking dependencies for a while. They've got a platform in place to do it, so that can help a lot. And then Edna also said something really interesting about penetration testing. When your pen testers are coming in, they're seeing what different services, your web application or the application they're testing they're seeing, what those are connecting to. And that can be really valuable. You might want to ask them to report back on that, especially if it's a third party testing group, because they've been tasked with testing your app.


Diana Kelley:
So, they're going to tell you where your code has vulnerabilities, but often they see as they're doing that test where your connection points may have vulnerability. They definitely see the connection points. They may also see some vulnerabilities or exposures there. So, as they're doing the testing, you might want to say to them, Hey, if you see that I'm using a form builder, that doesn't look right to you include that in the report. Don't just tell me where I've got issues with my HTML headers exposing too much data. Tell me if you see anything that's part of my whole service that I look at too.


Kacy Zurkus:
So, I just want to follow up on that because we've merged the two different actions. Of inventorying there's the inventorying and understanding of your immediate software supply chain dependencies. But then there's also, as Edna said, the inventory and tracking of your third party offer a supply chain. And I want to make sure that our listeners understand that those are two different questions. And so, how are they distinct? But I guess conjoined as well.


Edna Conway:
They had better be conjoined twins. Let's put it that way. I don't know how you can separate them. You can't have a build manifest that articulates what your own internal developers have done without understanding what they've extrapolated from the world of competency that's out there that we can access, whether open source or proprietary that you're licensing in.


Edna Conway:
So, to me, while they need to both be looked at, they need to be reviewed and documented in a similar way and housed in a similar repository. And to the point that Diana made, when you are doing testing, let's recognize that just because they test sounds like use her example, pen testing it's for security. It doesn't mean that there isn't valuable information that provides you with inventory insight that could be in your build manifest that validates even the best of the best who already have build manifests long before the executive order on SBOM came into being. You still need to say, let me check and see if it is what I think it is.


Edna Conway:
And just plain old fashioned updating. I don't know how you update if you don't know what's in there. So, take the S away from the developing life cycle. So, it may not be an SDL, but just development life cycle, you need the recipe, unless you're just one of those really gifted cooks who goes into the kitchen and makes things, the rest of us we need recipes. If the recipe is not available and the recipe isn't updated to the fact that six of your family members have an allergy to ingredient, why? You have a problem on quality, not just integrity.


Diana Kelley:
Yeah. And it seems we always talk about food Edna. I can't imagine why with the two of us, but I love the food analogy to help answer your question, Kacy which is... And Edna was basically going here. So, let me just continue on her path, which is that, when you're thinking about the software you create or the widgets you make, versus the ones that you buy. It's a little bit whether you buying a cookie or you're baking a cookie at your house, in both cases, you've got this cookie in your house and people are going to be eating it. So, as Edna pointed out, so you've got a family member that's allergic, it's on you to understand the ingredients in the boxed cookie and the ingredients in the cookie that you make. And as you can imagine when you're making it yourself, you have a little bit more insight, a little... It feels a little bit more transparent. If you buy a cookie and they don't have the ingredients, you're at a bit of a loss.


Diana Kelley:
So, that's why talk to software vendors and builders that will give you some level of transparency into the ingredients that they've got either in the software or that they built your widget. Let's say a laptop. When you make it yourself, you have a little bit more control, because you can pick some of those ingredients, but even those ingredients may have other sub ingredients and staying on food here, eggs for example. If someone has a soy allergy, but not an egg allergy, you may think that you're fine putting an egg into food that you're going to feed them. Well, actually you're not because most layer hands in the United States are fed a soy based pellet. And so that if you eat eggs that were made from a hen that was eating these soy based pellets, someone is allergic to soy is going to have an allergic response to the food, with the eggs in it that you feed them.


Diana Kelley:
And that is a little bit where we get back to let's loop around back to software Log 4j for example. There were third party commercial vendors that have Log 4j in their software. So, companies actually had the vulnerability in their organization. They thought, well, I've got the ingredient I bought this vendor or that vendor. So, that's a known entity, but that vendor had that dependency within the software. So, that you actually had Log 4j in your organization, even though you didn't... You might not have had it inventory separately. And that goes back to that first layer or second layer. But as Edna pointed out, they do have to be conjoined because whether you created the software yourself or you bought it, it's still software that's running in your organization. So, it's just like its food, you're feeding to your family, whether you made it or you purchased it pre-made.


Kacy Zurkus:
So again, I love having these conversations with you because you make me feel like I get it. You use these analogies that are just so human and understandable and I'm like, wow, I could even do that. That makes so much sense.


Diana Kelley:
The food really.


Kacy Zurkus:
You can do it. You do, do it. So, I want to talk about the software bill of materials, the SBOM that's come up quite a bit. And not so much what it is. I think we know the definition of it, but rather, how can we use SBOM in practice? And I want to go back to a comment that you made earlier, Diana. You said, "if your supplier has an up to date SBOM all the better." So, what are the variations and iterations of SBOM that you want to be aware of as well when we're talking about using these in practice?


Diana Kelley:
Yeah. I think that the biggest one is making sure that you've got something that's up to date. Pushing code very quickly is part of what happens. This is the whole CICD we shift left. We push code all the time, very large companies that have web-based applications, in cloud native, mobile applications. They'll push code constantly even throughout the day. So, we're really far away from when it was... Well, let's take a look at this and we're going to test it before we ship tomorrow or something. We're pushing code all the time. And that means that if there's a new feature needed and a developer realizes that someone has made a really good version of this and they can access it over the web, they can pull in that service. Then it may make sense to pull it in from a pre-made version already then to incorporate it themselves.


Diana Kelley:
So, your SBOM from yesterday may not be current because that's the world that we live in. We move very fast with software right now. So, the biggest thing is to understand with the vendors that you're working with and with your own dev team, how are you keeping track of the dependencies and how often can it be updated. Right now there's really not that I know of a great automated version way to pull in all of the dependencies and nested dependencies from all the software that we are both building and we're consuming. I hope that now that there's such a need for it, that we'll see some better offerings in the market, but until then talk to your vendors and talk to your own development team about how they're keeping things up to date. And I'm not a fan of saying manual is great, automated very... I love automation and it's helped us to do so much, but at this point, really smart manual listing and recording of the dependencies within your software is where some companies are.


Diana Kelley:
And if you've got very smart product engineers, whoever's going to be in charge of this. Either the head of engineering, the CTO, the product manager, whoever's got that list of dependencies and is keeping it up to date for that product line, as long as they can keep it up to date, even if it's a spreadsheet, is it ideal? No. Are we at that point? We've got continuous real time views also, no. So, if look at something with people really staying on top of this, having a process in place so that they know how to update things, start to build some bits of automation into the process so that they can do updates fast. Maybe it goes into a repository, shared collaboration of wanted... Edna was pointing out that can get you a little bit closer to full automation. Someday we're going to have full automation. We're not there. So, we need to have people and processes to make sure that it's getting done now.


Edna Conway:
Let me put in my plus one thumb on automation, I think the promise of an SBOM can only be realized with machine readable, less bonds, that support automation and tool integration. They have to have that. And why, because at the end of the day, it is at its infancy, a set of data. And so applications have to be able to query the data. But I had to make a proposal that we look at an SBOM, just like any other bill of materials, which we have H-SBOM and we have D-SBOM. The reality is its true growth lies in the ability to not just query the data, but process the data. And so many folks, me among them have said, please let's try to minimize the regulatory burden on those of us who are building things into our processes already, because sometimes you go down to the denominator of just compliance.


Edna Conway:
And that actually takes us to a place that's not the most effective security and integrity and reliance capabilities that we should have. But in this case, I'm going to say, if you have the minimum elements and NTIA put them out. You need to know the supplier name. You have to know the component name. You have to know the version to Diana's point. And let's throw some cryptographic cashes in there. And a whole host of other things including who. Here's a novel thought who authored, yes SBOM data. Don't forget the elements of humanity and the enterprise as well that acts as a person in this case. But where we could get to. Let me give you the pipe dream. The pipe dream is full integration on not just querying, but action processing. So, it's integrated into the build process.


Edna Conway:
All my developer is committing to my code. That's beautiful. I got version control, I've entered it into the build system. The build system compiles the code we generate and sign the code and we generate and sign an SBOM. And the SBOM gets published into that environment as a build artifact that gets stored and a long comes attacker X, and they tamper at the artifact store, it's a good place to go. I like tampering with artifact stores. I'm going to replace the genuine artifact with a malicious artifact. And guess what? The next step happens. Release management system says, "yep, I've got a release, here we go." And it took it from the now a maliciously altered build artifact. It publishes a malicious release artifact to store.


Edna Conway:
Guess what happens? The release management system attempts to verify the malicious artifacts against the signed SBOM. No verification fails. Hampering alert. The tampered release does not deploy. That's when we have Nivana where we can actually use an SBOM to defend against APTs. Wouldn't that be grand?


Kacy Zurkus:
Nivana would be grand. Yes. It's a good goal. But shy of reaching that, how do we in practice use form. When it comes to protecting the supply chain and vetting our third party or fourth party or down line suppliers?


Edna Conway:
Look, even if it's manual, if you know who, I know what supplier and better yet I know what component. Even if I just had that. And I know where I put it, let's say I don't have the cryptographic cash, but if I know those fundamental things, what I can do is implement a vetting process, which we've done. I've done it at another enterprise as well, where you effectively create an architecture that looks at security criteria, resiliency criteria. But what you do is you apply that architectural set of controls informed by who, number one, what they do for you. And if it's software where that software is deployed, because I might care about a software that is in the core of my functionality very differently than it's enabling, let's say a cloud service, as opposed to software that is doing something like... I don't know, speech to text recognition, not that that's unimportant, but may or may not directly affect functionality.


Edna Conway:
And that architectural approach, Kacy allows you to vet based on the nature of what that particular code set and third party do against the controls you put in place leveraging as well. If you can, international standard certifications and anything else that they have that shows you what they're doing.


Edna Conway:
And the other way you really want to vet is you want to vet that they are giving you evidence of conformity against those controls. And I think Diana's going to add, and I bet she'll take off of this. She said at the beginning, "let's remember, it's not just the first relationship you have. Go back to the cookie. You buy the cookie, you still need to know the ingredient, but the ingredient provider has a slide chain as well." And that's really important to know. And that's something you have to build into your vetting process that says, show me how you are actually mandating, or at least partnering with your third party ecosystem to make sure that the standards you've just shown me, you adhere to... Which I'm very appreciative of all, are actually utilized and adhered to successfully down the chain, that's your chain. That's where the ticket lies in success.


Diana Kelley:
Yes. And looking at this, there's two modes. There's acquisition mode and there's ongoing run mode. And an acquisition mode, exactly what Edna's talking about. Do I want to do business with you? Well, how do you create your software or your laptops and what are the components that go into those? And do I feel comfortable with either those hardware components and the physical one or the software components. And then that's how you're making your initial acquisition decision and also your own developers as they're building software. Do I trust this library, for example, am I going to put that into my build? But then there's also the other really, really important thing in terms of security here is, what happens when things goes sideways. So, that was a great library when you incorporated it, but what about now? Or we just found out there's a zero day.


Diana Kelley:
The open SSL issue from a few years back was a real heart bleed was its quote name. But anyway, this was a big problem because it was in so many products and companies were, are we vulnerable? They didn't even know. Because, how do we know? Where are all of the different pieces of software that are running open SSL in it? So, they had to then go and look at their own stuff, talk to all their vendors. It was a big mess.


Diana Kelley:
Are we better? Well, that was years ago. We're fine now, everybody knows what's... Do we though? Because, the same fire drill just happened a couple of weeks ago with log4j. So, you want to know what's in what and how you're using it both when you acquire it to make sure you're making good acquisitions or more good build, but also so that when something goes sideways, like log4j you can immediately say, this is all the stuff we've built, where we're using it. We've got it all updated. And this is all the stuff that we purchased or have subscriptions for from our third parties. And we know that they're updated too. So, that's where that insight and that line of sight of what you're using where really helps you in run time for resiliency and security.


Kacy Zurkus:
Yeah. And that's not the sexy cybersecurity conversation. That it's that... But it's the work that needs to be done so that when that log4j happens, you are resilient and able to just move forward without a huge impact.


Diana Kelley:
And I think also given when log4j occurred, I can say it was actually sexy for some people that were very prepared and had really good lists of their dependencies and knew where they needed to go and patch. Because they were going to holiday parties and getting enough sleep and being already for what they were doing over the end of the year, as opposed to some other people that were literally not sleeping for days at a time and not able to be with their families or to go out to parties. So, there was a sexy element of being prepared, I would say.


Kacy Zurkus:
Absolutely. I just had that conversation with Caroline Wong when we did our advisory board conversations and she's like, we tend to hold up those that spend the sleepless nights responding. But I think we really want to be celebrating those who did the preparation and that's how you're able to spend the time with those holiday hours with family and loved ones instead of responding to incidents.


Diana Kelley:
[crosstalk 00:35:00] No shame for anybody that wasn't prepared. I just want to say that, I don't mean to shame anybody because-


Edna Conway:
No, you both said it elegantly. I think what we ought to remember is, and what I've seen as a shift is, that even as recent as three years ago, you did not see in incident management, a standing placeholder discussion for supply chain. I think today's incident management methodologies have put supply chain as a critical ask each and every time. And so that is a marked improvement where at least it's at the table and it may very well be that it's not impactful, but asking the question is step one. But without the preparedness to have the information, all you're doing is sitting there saying great, what's the impact on the supply chain? The answer is we have no bloody clue. That's not a great answer. And you can go address it manually, but you go through that twice and I guarantee you, you will not want to do it again.


Kacy Zurkus:
Absolutely. So, this has been an enlightening conversation and I love when I'm able to follow along and understand. So, I appreciate that very much. You've given our listeners a lot of good advice. Before we wrap up, do either of you have any additional parting words of wisdom you'd like to share?


Diana Kelley:
Mine would be. I know that we want full automation, but right now most companies aren't there yet. So, don't be afraid to create a process and get it in place now, because this isn't about waiting for perfect. This is about actually getting it started in your organization and talk to your developers. And if you've got really smart dev leads and really smart procurement, that they keep a lot of us in their head, help them to get it out of their head and into some shared repository. So, that when the next log4j comes down the pike, you've actually got something that everybody has worked on, that you can go to and, and look at. And again, most importantly, we're not at full automation, but don't let that stop you from getting started and getting some program in place now to manage your supply chain, especially in software, which has been left off from a lot of companies.


Edna Conway:
Yeah. Let me pivot off of that and say two words. Information sharing it's okay to do. And not only is it okay, we should do it. There is still some reticence despite the world in which we operate, where we have crowdsourcing and open source software. The reality there is still a reticence to do that. And we need to eliminate that from our culture as a community, because that will get us started in the right way as the Diana just articulated because I'm going to hold out for Nivana. But I am a practical person with my feet firmly on the ground. We have to start somewhere. And that starts with information sharing.


Kacy Zurkus:
Yeah. I love that. That's great. Great guidance from both of you, Diana and I thank you so much for joining us today. Listeners, thank you for tuning in. To find products and solutions related to protecting data and the supply chain. We invite you to visit RSA conference.com/marketplace. Here, you'll find an entire ecosystem of cybersecurity vendors and service providers who can assist you with your specific needs. Please keep the conversation going on your social channels, using the hashtag RSAC and be sure to visit RSA conference.com for new content posted year round. Thank you all. Have a great day.