 And we're back, I hope that you had a good time having a coffee, a beer, or a latte. Now we're moving on on DevSecOps with Alyssa Miller. She's a hacker, a security advocate, author, professional and public speaker with almost 15 years of experience in the security industry. She has always had a passion for deconstructing technology, particularly since buying her first computer at the age of 12, teaching herself basic programming. In her career, Alyssa has performed all forms of security assessments, but given her developer background, she had a dedication to application security. She specializes in working with business and security leaders to design and deploy effective security programs that create a true culture of shared responsibility and developer enablement. So big round of applause to Alyssa Miller and her talk on Look, There's a Threat Model in my DevSecOps. All right, well, thank you. Hello everybody. So I am Alyssa Miller and yeah, today we're gonna talk all about threat modeling and how we bring threat modeling into the DevSecOps environment. Really quickly, I had a pretty good intro there, but just to go through it again for you. I am a hacker and a researcher. I've been a hacker all my life. I am an application security advocate for a company called Sneak. I'm also an author and a blogger and also not mentioned, but I'll throw it in there. I am also the co-host of a podcast called The Uncommon Journey where we really focus on people's unique stories for how they got into the security community. But today, like I said, I wanna talk to you about threat modeling a bit and I wanna talk to you about threat modeling in the context of a DevOps or a DevSecOps environment. So taking you back, I wanna tell you just first a little story. When I was working as a consultant, which I did for many years, I was working with this organization and they had a really terrific threat modeling program in place. They had a really streamlined, they had a really good methodology for how they did this. They followed it consistently with every project. And we as consultants, we helped them build it and then later on we helped them execute it. And I just remember the day sitting there in one of these sessions where we did the threat modeling and design review for a particular application and we got done and I walked out and we were kind of chatting outside of this conference room and the one developer comes up and says to me, you know, God, I'm so glad we're not gonna have to do this anymore. And I kind of looked at him sort of quizzically and asked, what do you mean you don't have to do threat modeling anymore? And he says, well, we're converting our development over to DevOps. And it just got me thinking, like why is it that we see threat modeling and DevOps as mutually exclusive concepts? Threat modeling is this critically important thing that we try to do from a security practice perspective. And yet the assumption was made that it was completely incompatible with the DevOps approach. Now anybody who's done threat modeling is probably gonna recognize this book. This is the book that Adam Shostak released many years ago detailing some of the methodologies around how we conduct threat modeling. And it's very comprehensive and it produces a lot of guidance and a lot of things that people will reference around how to conduct threat modeling. But it also introduces some of the reasons that I believe are why we see threat modeling not being conducive to DevOps. Within those processes, we see things like these diagrams the data flow diagram, the attack chain. We start talking about different frameworks like stride for how we classify different forms of threats. Then we talk about dread. How do we actually prioritize these different threats and understand the risk behind them? And we see threat modeling become this very onerous and very heavy weight process. And it's very technically focused as you see with stride when we're talking about things like spoofing and tampering and denial of service and refugiation and all these different things. And it's really based on a point in time. And it's so technically focused that it starts to lose business context. And as a result, when we look at it, it just looks heavy and brutal. And every time we try to make it more simple, for instance, we come out with this idea of the capex taxonomy, which capex is gonna define all of these common threats and make it easier for us to understand. It turns into something like this. And it just always seems to be more and more difficult. Well, in 2008, we kind of blew this all up, right? 2008, this thing called DevOps shows up at our doorstep. A couple of guys in Belgium decided, hey, why can't we streamline development, give developers better capability to deliver software quickly and efficiently? And we start to look at threat modeling and boy, from a security perspective, we've been talking for two decades about how to push left and DevOps seems to make that harder than ever before. How do we inject security into a DevOps life cycle? And so one of the ways that I'm going to tell you right now that I believe it is key to making this happen is bringing threat modeling into that DevOps environment. But when we think about threat modeling and we start to talk to the development teams about what is threat modeling and why do we do it, you really struggle to find a definition. And so if I'm gonna justify to developers on why it is that we need to do threat modeling as part of their DevOps pipeline, I need to be able to justify the why. So I went looking and I figured, well, where better place to start than start with OWASP, the kings of application security. And when you look for a definition of threat modeling, this is what you get back. Now, I'm not gonna read this whole thing to you because the point is it's this long lengthy definition and reasoning behind why threat modeling is important. But how can somebody take this and internalize this? When we're looking at DevOps and we want things to move efficiently and to be consolidated into resources that are all working towards a common goal, big definitions like this are not the place we wanna start. So, okay, OWASP can't help me out. Well, what about Wikipedia? Anything, if it's not Wikipedia, it's real, right? You go to Wikipedia, it's the same problem. It's still this complex description that when I take that to a development team and I say, hey, I want you to do this threat modeling thing. And I try to tell them that this is the who's and the what's and the why's. If it's this complex, just understand what it is. My gosh, how complex is it to really implement this in our pipeline? So, still not happy. Well, I mentioned Adam Shostak's book before. You know, Adam Shostak worked for Microsoft and Microsoft has been one of the leaders in terms of the Microsoft SDL. They talk about threat modeling all the time. So, they must have a better definition, right? Well, it gets a little better. They've shortened it. They focus a little bit more on some of the things that are inherent to threat modeling, like identifying threats and attacks and identifying countermeasures that could affect your application. Okay, we're getting closer to something that makes sense, but we still struggle here. And I, it got me to thinking, none of these just seems like a good comprehensive and concise way to describe to developers, here's what threat modeling is all about and here's why it needs to be part of your pipeline. So, I thought to myself, it's time to get back to basics. Like, why do we do threat modeling? What is the reason? What is threat modeling really at its core? What does threat modeling do for us? And if I dial it all back to its simplest form, threat modeling is basically asking the question, what could possibly go wrong? It's looking at a system. It's looking at an application. It's looking at whatever business line it is that we want to understand better and asking ourselves just quite simply, what's the thing here that could happen that would be bad for our business? And then I found the definition. Why do we threat model? It's so that we can identify the likely threats to a system to inform the design of security countermeasures. That's it. At its core, that is what threat modeling is all about. Now, where did I find that definition? I had to make it up because it doesn't exist out there anywhere. I can't talk about simplifying threat modeling to the point that we can fit it into a DevOps pipeline if I can't make the definition itself simpler. So this is where I wanna begin. But why is this important? Why do I care so much about threat modeling that I say it's so crucial to our development cycle? Well, think about what we do with a threat model and how this works. How does threat modeling actually inform our development? So I performed this threat model. And in the traditional sense, it was a point-in-time activity. We'd take some time, maybe a couple of weeks to drop these diagrams and analyze threats and we'd produce some type of documentation coming out of that. That documentation then feeds into the planning phase of development where we define security requirements. But it doesn't stop there. No, we move from the planning phase to the build phase. Are these looking like familiar phases to you? If you know DevOps or you know DevSecOps or even if you're an agile, you've seen these before. So our threat model feeds from those security requirements into the design of the security controls that we're building in our application. But indeed, if we're doing things well and the reason that we want threat modeling is it goes beyond. So now we built these security controls. Our threat model now informs our test cases. So now that I understand the threats to my system, I understand what is most crucial for me to defend about this application. It tells me those are the things I need to be testing for. So my test phase now, I have increased the effectiveness of that test phase through my threat modeling exercise. And then finally, that threat model when it comes time for me to deploy, it's telling me what are the critical areas of this application I need to be monitoring. What matters most to me when I deploy that application and how do I construct my monitoring to accommodate that? But then I throw this at you. And once again, we have this concept CICD, right? Continuous integration, continuous deployment. Well, Lissa, how are we gonna do threat modeling when you're telling me that it's this, I gotta drop these diagrams and I've gotta understand this system from end to end. How do I fit this into a CICD environment where I'm constantly planning, coding, building, testing, releasing and rinse, repeat all over again? It doesn't work, I can't do that. Well, when we talk about DevOps or DevSecOps, yes, CICD is often the goal, but there's another goal. Let's talk about the other CI. So we think about continuous integration, we think about continuous development, but when I talk DevSecOps, we also talk about continuous improvement. We are always looking for that feedback cycle by which we get continually better. And what continuous improvement means is we're not trying to boil the ocean all at once. There's no expectation that we're going to make our systems 100% secure or perfect today. No, quite the opposite. We understand that this is a process by which we slowly get better over time. And that's exactly how we wanna approach threat modeling. So what I'm telling you today is that threat modeling doesn't have to break your DevOps pipeline. And we're gonna look at how. So I mentioned already the goal of DevSecOps, being bigger than just speed, right? It's this idea of continuous improvement. When I look at the core of what DevSecOps really is, it's this idea of a culture. It's a culture in which responsibility for delivering secure code that's stable and efficient into our environment. It's a shared responsibility across the organization. Sure, we call out developers, security, and operations with DevSecOps, but it's even bigger than that. It's an entire organization where people aren't able to share in the responsibility for creating secure software. And that means that it includes not just technology and tools. So often we talk DevOps, we think about the tooling behind it. How do I build an automated pipeline? But it also means the people and the processes and the governance that come with it. We've been talking for years about push left, how security needs to push left. Well, DevOps, we have developers pushing right. We've got operations pushing up the stack. We've got everybody pushing every direction in this realm of shared responsibility. So when I start to think about pushing left and I wanna bring threat modeling into play in an area where it's not going to slow down my development, it's going to be frictionless. What is the farthest point in my development cycle that I can push left? It's the user story. Threat modeling needs to begin with the user story. And who defines our user stories? It's not our developers. It's the business people. It's those product folks who are writing these user stories. If they can capture threat modeling information for us at the point that they write the user story, I already have that information in place that's gonna inform my development at the point that that story comes off the backlog and becomes part of a sprint or it becomes the next piece that we're going to develop. So this idea of data flow diagrams that we used to do, we don't need this. If I break it down and I look at the user story, am I going to threat model the whole app in one user story? No, again, I'm thinking about that idea of continuous integration, continuous deployment, which also then includes continuous improvement. So if I want to continuously improve, I just need to do a little bit every day with each new user story. How can I understand this better without having to do these big, massive data flow diagrams that cover the entire gamut of my application or my system? So I want my business people. I want the people writing those user stories to tell me in the context of that user story, what's the worst thing that could happen? And to start with, I just need them to identify for me, what are those critical assets that are a part of this user story? What's introduced or what is leveraged in this user story that is most critical and most critical from a business perspective? I don't want to talk IT here. I want to talk about the business and understand the business context. Is it private data? Are there critical functions that we need to defend because they go straight to our ability to deliver a service? Are there financial assets at question here? Are there people assets that we need to defend? How often do we forget to consider people as assets when we talk about the critical assets of our organization or of our business line? And what are the other secrets, whether they're IP, whether they might be secrets in terms of just trade secrets or whatever things that we need to defend within that user story? That's what we want them to focus on and we want this information included in the user story. But then we want to go beyond, we need to understand the threats now that those particular assets face. So by introducing this critical function or by introducing the fact that we're going to leverage this personally identifiable information, what are the threats? But again, I'm talking to business people and I want business context. So I don't want them to break it down into stride. I don't want them to have to understand what is spoofing or what is tampering or what do I mean by repudiation. These are technical terms we use in the security community. I don't need them to understand those particular concepts in order to give my development teams the information that they need in order to design and develop security controls that make sense and address the threats that matter the most to that particular user story, to that system that we are modifying as a part of this new development. So instead, I want them to focus on threats that have business context and what do those threats look like? Well, they're pretty simple to understand in plain English. The first is theft. Is there the threat that someone is going to try to steal something from this user or via this user story? If I'm using personally identifiable information or I'm leveraging financial assets, those might be things that people would try to steal. Could they commit fraud? Is there something in this user story where I'm introducing new functionality or new data that could enable fraud? If they can manipulate how my system helps me to make business decisions, if they can manipulate different transactions within that application and cause fraudulent transactions, that's a simple concept that people can understand at a business level and they can prioritize this from business context and provide that information to a developer. This is that common language that bridges that gap. Exposed data. So again, thinking PII, of course, this is one of the ones that we think about most often. Is there the threat of a data breach? Could data be exposed? Could secrets be exposed? Trade secrets, things that we need to protect most in terms of intellectual property? Are those things, are those threats that are introduced now as a part of this user story? And then finally, is there, if I've identified critical functionality, there's probably a threat there that if that critical functionality is somehow disrupted, it would interrupt our business. If we are providing a service to our customers and there's a threat of interrupted business, that's something that from a business level is important to understand. We need to start to define security controls that surround that. And so this is the information that I want the people who are writing my user stories to start to pass on to my development teams. So I can capture this in however it is that I'm capturing my user stories today. I showed you a screenshot from one particular backlog management tool. How do you manage your backlog? You have user stories, you have product people writing these. Most of the time backlogs are in some automated system. Add a couple fields with a couple simple prompts to ask your product people to identify those critical assets and those critical threats in turn that are a part of that user story. This is what we want to start building. Now we've pushed as far left into the process as possible and we've done some basic threat modeling without affecting developer timelines or increasing friction for the development team. But where do we go from here? Now typically this is where we would move in the threat modeling traditional sense, we had moved into this idea of attack chains and we would try to document attack chains. And from attack chains then we would start to say, okay, well I see up here there's the threat of blackmail or eavesdropping. I see that bribery is possible and so I wanna start to design countermeasures around this. This is all great. This is what we call design thinking, right? And I know that's not always everybody's favorite term to use especially from a developer in a security world but the fact is design thinking is real. Whether we do it as a laid out process or we do it in our own minds as part of a very fast and efficient DevOps model where I count on my developers to do that thinking that's happening somewhere in this process. I am taking as a development team those requirements and those concepts that are documented in my user story and I'm turning that into a design. So if now I have information about threats I can build this attack chain in my head rather quickly. I can do that design thinking without the need to build these big diagrams. So again, we are moving away from a lot of this onerous activity that makes threat modeling feel like something that's just completely incompatible with our DevOps processes. And instead we've moved it into something now that we can empower our developers to do just as a part of their daily course. So how do I take this and break this down for a development team? If I don't want them to develop these attack chains what are they going to do instead? How do they go about designing security controls that fit that user story? And what I'm gonna tell you is I can break this down into three types of controls. And if you take each threat that's documented in that user story and look to implement one each of these three types of controls starting with those critical assets identified you're going to be achieving that continuous improvement you will get a little bit better today than you were yesterday. So the first type of control we're looking for is that detection control. What can I build around this critical asset that can detect that incoming threat? So if I've got critical data sitting in a database how can I build monitoring maybe in the form of logging maybe in the form of alerting something how can I start to develop that detection technique that's going to let me know when someone accesses that data unexpectedly or my application accesses that data in a way that was not intended. Building this type of control gives us that first step. Okay, now I know something is wrong. I have those people who are charged with responding to these incidents within my organization and I've ensured that my piece of this system that I'm creating in response to this particular user story that's a part of my sprint I've made sure that now I've implemented that level of detection just strictly in the context of that particular story. Again, I don't have to implement some wide ranging logging and alerting system across the entire application. That's a heavy duty initiative and it's something that probably is not gonna happen quickly within a DevOps approach. It's going to be very difficult to make that happen but now I've given you a bite-sized chunk that makes it a little easier. The next control then is a mitigation control. Now I'm using the analogy here from Star Wars because everybody loves Star Wars, right? You think about shields or if I take another metaphor I really like to use here and it's always the dangerous one when we're in security but talking about castles. You'll get castles and how they were built. You have all these types of defenses in how they build a castle. So you had concentric walls that were built out from a central structure which was what they wanted to protect and between those central walls you had this space. Those were that space whether it was a moat whether it was just an open yard. Those spaces were mitigation controls because what a mitigation control really is is just something that's meant to slow down an attacker. It's meant to give us the time and space to respond. So now that I have my detection defenses that are alerting me to the presence of a threat I now have the ability to slow that threat down so that my responders can react quickly. So there are various ways to do this within an application. It might be layers of authentication. It might be things that we do from an encryption perspective. Whatever those controls may be we need to build those controls and that even once an attacker breaches that system we can slow them down. At a larger system level beyond the application space if we start thinking in larger terms this might be segregation within our application. Maybe it's a microservices segmentation where I've got different microservices that are responsible for different pieces. So I know if this microservice gets breached it doesn't necessarily affect that other microservice and they have to still spend time trying to breach that next step. And then finally we have our active defenses. So again, keeping with my Star Wars theme here those are the defenses that really launched to stop and attack. So this could be any number of things. This could be the ability to shut down users. This could be the ability to relaunch a particular container. Lots of different ways that this can be accomplished. But if you take these three forms of security control and you build this around each asset and therefore to address each threat that was identified by your business people in that threat model you're now getting a little bit better today with that next deployment than you were in the previous version. And that's the goal of what we wanna do with threat modeling when we're talking DevSecOps. So it's just about time for me to wrap up but before I go I do wanna leave you with this quote. And unfortunately I cannot find attribution for this one. I just happened to find it on the web and it's stuck with me. We can't change where we're headed if we do the same things that got us here. If we keep thinking about security as this gate as something that sits between phases of the development pipeline and so forth we're never going to get any better. We need to bring security in to be a part of each of those phases whether it's planning, coding, testing, deployment or anything in between. Security doesn't stand between those. Security needs to be a part of those. So finally before I go I wanna leave you with an invitation to continue this conversation. My Twitter handle's up here. My LinkedIn information if you'd prefer to reach me there or my website where you can also view my blog upcoming speaking engagements all that sort of thing. Please feel free to reach out to me as a security advocate in a lifelong security evangelist if you will. I'm always looking forward to having those conversations sharing ideas with people and sharing what you have to say, sharing what I think and seeing how we can work together to get better. So with that on behalf of myself of course my employer who enables me to be here today and of course North Saccon I just wanna say a great big thank you to all of you for being here today for your attention. Certainly appreciate all of you. And I believe at this point where you are going to open it up for some questions. Hi everybody, let's wait a little bit so everybody can look at the questions maybe ask them or a vote. We'll be back in like two minutes. Hey, we're back. Okay, so let's go right away in questions. The first one would be you seem to suggest we shouldn't do large diagrams of the whole system between iterations. Sure, but isn't it good to start with a baseline big pictures view? So yeah, so the thing is with the big diagrams, right? They can be helpful. Don't get me wrong. I'm not suggesting there isn't value to a data flow diagram or a large architectural diagram. They're certainly helpful and they're certainly great to have because they provide much needed context and visualization. What I don't like to see though is those as a part of the development process. And so when I talk about threat modeling specifically with DevSecOps I'm talking about making threat modeling a repeated process that happens within the context of the pipeline. And so if it would make sense certainly to have an initiative that doesn't affect iterations, doesn't affect your sprints, doesn't affect the adoption and development of user stories. It would make sense to do that or if you have the luxury of doing that at the very inception of a new application, great. But that shouldn't be something that is a requirement of each project or each release or each version because that's where again, we get into that form of security being a gate rather than just a part of the stages of development. Okay, okay. Other question, as the scale and complexity of infrastructures keep growing what is the place for automation in this very intuitively human process? You know, I wish, yeah, I wish I had a good answer for it because obviously when we talk DevOps or DevSecOps or CICD, automation is where our minds go right away. And I've seen some really valiant attempts at trying to automate threat modeling. Unfortunately though, I've not seen a solution that I can say today I've looked at and I've looked at a lot of them that I felt was really there where we could just count on an automated solution to do this. Where I prefer to see it if we want to automate it, it's we're creating the workflows and process so that part of it can be automated. But I think at the end of the day, we still there's, I don't see, as you mentioned, it's a very intuitive process. And you know, unless AI proves to be some, you know, second coming for us, which I still am very skeptical of too, I don't think that that's gonna be the process that's gonna get us there either. We still need with threat modeling that human intelligence because we need to be able to understand so many variations of what's critical to the business. What's an asset? What is a threat? Someday if someone can invent the language to define all that and turn it into automation, that would be great. I just, I haven't seen us get even close to that yet. It's interesting just because it goes against like the industry where they always talk about the solution isn't automation and AI. So good to go on the other way, I agree. What do you think about the pasta methodology which is the process for automation, simulation and threat analysis by Tony, you say developers? Do you think it's an approach which is compatible with the BSEC ops? With modification, which is really kind of how I feel about all of it, right? You know, it's, you look at pasta and unfortunately the way it typically gets adopted, it still comes off as pretty heavyweight. And I think you can take it. I mean, even going back, I can, you know, I can say you can take Adam's show stacks book and you can adopt that. I mean, anything I said isn't necessarily conflicting with that threat modeling book, which is kind of the Bible for threat modeling, right? It's, you know, even within that book, Adam had enough forethought to say, you know what, look, this is, you need to adopt the practices that make sense for you. And as we get into more dev ops, there's parts of it we need to drop or adjust. So you can definitely take pasta and you can leverage it in a way that makes sense within a dev ops model, but it does need some, there's some tweaking that has to happen. You do have to kind of adapt it to what you wanna do in your pipeline. Yeah. Okay. How do you know which story is relevant for the threat modeling activity? Well, because if you're the one writing it, you're the one who is doing the threat modeling. And that's really the point. That's why I'm saying where, you know, a lot of us within our backlogs, we have a backlog management system with kind of a standard template for documenting your user story anyway. So just adding these couple of questions of, okay, what are the critical assets? Have that person identify the critical business assets and then ask them, okay, based on those critical assets, what are the threats? And just having to find a few, they don't have to be comprehensive. Cause again, here we're just trying to get better. People intuitively will think of kind of the worst case scenarios. And that's what we wanna be defending against. You know, inherently how we prioritize things anyway. So where it's a choice of not doing anything versus doing this type of threat modeling. This is what I wanna see. Yeah. Next one, sorry, there's a lot coming up. Okay. Threat modeling happens at design time, I guess. Do business owners have enough information to think through and write user stories to come up with non-functional requirements? Well, see that's the thing, right? So they have the business context. So they obviously have enough business context to write a user story. And if I have a user story and I can look at it, and this is why I simplify what I call an asset and what I call a threat. If I sat there and I said, okay, based on this user story, I want you to classify all the threats in terms of stride. No, I don't think business people would be ready to do that because stride is so again, very technically focused. You need them understand, well, would this be spoofing? Would this be tampering? I don't know which. I'm not looking for that. Tell me in terms of this business asset what it means in terms of a threat. So if I've got financial assets, clearly my concern then is that those financial assets could be stolen. That's a theft, that's the threat is theft. If I've got a critical function, this is the thing that keeps the electrical grid running way over simplifying it, but bear with me. That's something that affects my critical business, my ability to deliver service. So rather than defining it as denial of service, just hey, tell me if this is a case of interrupted service as a threat. And so that's what we're trying to do at the business level. Then when we bring it into development, if I've got architects who take those first and put together a design or if it goes directly to my developers, they can now take that and make the translation because it's plain English. They've been giving that, they've been given that particular business context. They can easily convert that into, okay, now I understand that this might be ways. I have to think about how someone could leverage my design to steal, to conduct fraud, whatever. Great talk. Care to spend a second addressing how to tackle the inertia created by Stride and DFD, data flow diagram adherence? How to convince them of user stories that centric approach? Sure. So it's a couple of things. And this goes back to what I was talking about when I said culture and really thinking of DevOps or DevSecOps as culture change. DevOps was always meant to be a culture shift. It was not meant to be, when we say we have DevOps teams and things like that, I always kind of question what that really means because DevOps is a culture. It's, hey, everybody has this shared responsibility. And so in order to make security fit within that, security needs to be part of that shared responsibility. So instead of this gate where we've got a security silo who's gonna say yay or nay to moving on to the next phase of development, we need to move security into the phases of development so that it's part and parcel to that. That's breaking down that silo and generating that DevOps approach. So when we look at it in terms of people who wanna start to define the really stuck on, hey, I need my data flow diagrams, I need this or I need that. It's showing them that how that's incompatible with that idea of getting away from a gate because now those diagrams and things become part of that gate. And it's, all right, we're getting out of that gate mode and we're doing it this way instead because that makes us part of the development process. It's not easy with people who are very traditional and locked into those traditional approaches. But that's part of the overall friction of launching a DevOps model in the first place is realizing that we do have to do things differently than we did it in the past in order to make this new culture work. Continuously improving. Yep. One last question. Quickly, will the user stories be considered as features or enablers and how it gets prioritized then for threat model which supposed to happen earlier? So it shouldn't matter how it's classified ultimately. You should still be doing these steps as part of it. So if I'm calling this a feature, obviously there's going to probably be new data or a new functionality introduced as part of that. Okay, great. So I want to look at that and I want to understand what are the assets, what are the threats as a result of those assets? If it's enabler, it's still the same. I'm introducing new code that either touches new data, touches data in a different way. It may provide new functionality, whatever it is. It still has that same context of it's doing something different than I am today. So how does that apply to the business and what's most critical in terms of the assets that it's either using that it never used before or that it's going to use in a different way? Okay. I think we're out of time. Thank you very much, Alyssa, for presenting at Nordsec. We really appreciated your talk and having you with us. Please in the chat room give a big round of applause to you. That's how we can thank you. Well, thanks so much. I really appreciate it. I will be talking about quantum in eight minutes. So stay tuned.