Security vs Speed: A Culture that Chooses Both | DevOps Experience 2024

Hi, I'm Larry Matron, and I'm here to talk to you about the, the title of this talk, security versus speed, a culture that chooses both. So we normally think of security and speed as trade-offs, but the data does not back that up. The, the teams that are able to move the fastest are actually the ones with the, the highest security.

And, and, uh, I've not gonna spend a ton of time explaining why that's true, but I'm gonna describe to you how you get to a situation where that's the case. Um, and, and, and then you, you'll just have to try it to, to see, uh, how, how you experience that both going up at the same time. So I'm gonna give you a little provocative idea to sort of drive home this point of what I really mean.

And, and the, the, the provocative idea here is that, is that the way you do service level agreements for vulnerabilities, about 10 days for criticals, six 30 days for highs, 180 days for mediums or whatever the heck your SLAs are, are actually harmful. I, I, I think that if you, if you have any medium, any highs and any criticals, if you have any criticals, you shouldn't work on any highs. If you have any high highs or criticals, you shouldn't work on any mediums.

And you should focus all of the attention on the criticals first and get to completely clean and not just completely clean. Get into a blocking mode such that you never have criticals get into production again after that point. And, and so that's where the less than one day SLA comes from you.

You basically don't have a, a, an SLA on anything other than the, the part you're working on. And, and it, it gets, uh, resolved and stays resolved, stays clean, and then you start to work on the other areas and, and that is much more effective way of doing risk reduction. So, um, before I get too far into this, a little bit of back, uh, about my background.

So, you know where I'm coming from. Uh, there's some logos that are gonna come up there that sort of describe where I'm from and what I've done. But there's really two things I would I would like you to know about, about me.

First of all, I was the head of application security at Comcast, and most people realize in, in the states at least, that Comcast is a cable company. But, but there's a lot of properties and a lot of product development. 10,000 developers, uh, 10,000 people working on development teams and 600 different different development teams and spread across all sorts of business units that you maybe forget are part of the Comcast family, like NBC and Universal and Dreamworks and Peloton and, and Hulu backend.

And, um, uh, the, all the cable company systems in Canada, uh, are backended by Comcast, uh, products, et et et cetera. So, uh, all the ad placement. So there's a lot of, a lot of, a lot to that, to that environment, very diverse, lot of acquisitions.

Um, and I had to put in place a system that got developers to take more ownership of security over the course of five years. It took me, I got pretty much all the development teams to at least commit to doing that. I got about halfway there before I left.

Um, but then the, the commitment from the management was that we would do the rest and it was highly successful. Lower cost of running the program, AppSec program, and much higher, uh, uh, a much higher risk reduction, six success, better risk reduction than the prior way of doing it. Um, and, and the system I'm gonna talk to you about today is essentially that how you get to that culture, how you make that culture actually happen.

And, uh, the second thing I'd like you to know about me is that I'm an active developer. I write code almost every day. I'm the primary author of a dozen open source projects, one of which gets a million downloads a month, um, and is is, is used by, you know, all the cryptocurrency exchanges and every cloud vendor.

And, and it's considered critical infrastructure by the US government because they don't want it to be a vector for supply chain attacks. Um, and so it's, it's gotta be highly secure. And everything I'm gonna talk to you about here is, the way I run that project is there's a 20 or so contributors to that project, and I run it exactly like the system that I'm about to describe to you here, um, in this, in this, um, uh, in this talk.

Okay? So I'm gonna start with, with sort of setting the scene a little bit here. So, app and API security is fundamentally broken today.

And so, um, this is a pretty typical, uh, this is a cumulative flow diagram, but it's, it's pretty easy to to read, uh, if you've never seen a cumulative flow diagram before. Basically, this orange line goes up when new vulnerabilities are detected. This green line goes up when they're either marked as resolved or marked as false positives.

And then this blue one represents the portion that, uh, is resolved, um, as, as by being marked as false positives. And you can see here that, that this, this, this gap in the open vulnerabilities, it never really gets lower. And, and in fact, it's increasing dramatically.

And the only place where they, where they uced it dramatically is when they marked a bunch of stuff false positives here. And, you know, you could argue that they weren't really, they just sort of said, oh, we're just gonna declare risk, risk accepted, and, and, and move on. So, so this widening gap, we stopped getting bit dinged with this.

This is pretty typical. In fact, I see a lot worse than this at times, where the, the findings just run away from the resolution. And, and, and then you stuck with this inventory management problem.

And that's where the SLAs, the, the tendency comes into play. That 180 SLA tendency, of course, that just gives them permission to wait the full hundred 80 days before they get, they even think about it. And they're still not gonna think about it 180 days passed unless you ding them for being passed hundred eighties.

But you shouldn't ding them for that if they've got some criticals or even highs that are, that are open. And so this, this, this is fundamentally unhealthy. This is what a healthy cumulative flow diagram looks like.

Um, so you, it took 'em a little while to get going with resolution, but once they got going with resolution, it took about three months after the tools started detecting vulner vulnerabilities. And, um, they resolved them pretty rapidly. And you, you know, there's a little story about this, this spike in false positives for this team and this resolution, uh, ramp is essentially a representation of, of that because we changed the tool to the false positively because the tool was configured wrong.

And when as soon as we did that, we did that right here, boom. All those findings that were from that, uh, bad rule, um, got fixed. And so this way of running the program where you actively are trying to reduce false positives leads to better trust between the engineers and the security folks who are running the tools.

Um, and it leads to this sort of rapid resolution. And, and they're pretty much staying even with it evermore. Um, and, and you, you, you could look at this curve for just criticals and, and the, the, the, it would just shift to the left a little bit because the emphasis is to just resolve the criticals, don't even think about the highs.

And they didn't really start working on the highs till, till this, this steep curve here. And, and so this one has both criticals and highs being shown here. And there's no medium shown here.

This team never got to mediums. Um, before I, I left, uh, uh, Comcast, and this is, this is data from Comcast. I had permission to show, 'cause I'd shown it publicly while I worked there.

So I, I I keep saying don't work on the eyes until the criticals resolved. Don't wear the mediums until the eyes are resolved. Let, let's theoretically back that up with, with why that's the case.

And, and the theory is, is called the theory of constraints. And the idea here is very similar to the weakest link concept is that every human process and resolving vulnerabilities as a human process has bottlenecks. And if you make an improvement anywhere beside the bottleneck, it's just wastefulness.

So, and, and the weakest link con, uh, is the same concept. So if, if you improve the strength of this link, the chain doesn't get any stronger. The only link that you can improve the strength of and the chain will get strong, stronger is this.

And so I contend that finding vulnerabilities is not the bottleneck and resolving them is, and yet we spend a lot more energy buying new tools to find more stuff or better find stuff, um, more easily find stuff and rolling them out to far and wide without worrying about the resolution curves. We wanna get the tools spread across the environment. And then we think about resolving as a later, a later exercise when you'd be much better taking a depth first approach, depth first in terms of you install a tool in one team for one product, and then you expand it to a second product, and then you expand it to another team, expand it to a whole business unit, you expand it to other bus.

So deploy it that way. But every time you deploy it, you also focus on resolution, not just deploying it. You focus on just the criticals first, and then you focus on just the highs after that.

And then you focus on the mediums after that. And so it's a depth first approach rather than a breadth first approach. And we tend to take a breadth, first approach, um, to our detriment.

And that's sort of the, the one of the key insights to the whole program that I implemented at Comcast, that greatly reduced risk. Um, so about the time I launched the program at Comcast, um, I, uh, I wrote this thing called the DevSecOps Manifesto, the original one. There was another one that came, came later.

Um, and basically I've kind of drifted away from that a little bit, and I've even drifted, drifted away from the term DevSecOps a little bit 'cause it's gotten overloaded and it's, you know, misused. And a lot of people basically misused it by saying, let's slap some DevOps lipstick on a traditional security pagan, call it DevSecOps. And, and so I don't actually use the phrase DevSecOps any much anymore.

Um, even though my title at Con Contrast where I work now and help team companies to sort of implement this culture, uh, is, has DevSecOps, uh, uh, transformation Architect. Uh, so I, even though it's in my title, I still think of it more as developer centric or Shift Left or Ship smart or, you know, I, there's not a great term unfortunately, uh, for it, but it's all of these things. But all of these things mean three things to me.

It's empowered engineering teams taking ownership of the security of the products that they are building. So you build it, you run it, you've maybe heard in the DevOps world, you build it, you run it, you secure it is DevSecOps to me. Um, or you build it, you secure it, you run it maybe if you wanna get the order right?

Um, so they own it and they don't own all of it, and they get a lot of help from the security group, just like they get a lot of help from ops people. And particularly SecOps is still gonna be a separate, a separate thing for the foreseeable future. Um, but they own as much of it as possible and they are worthy of being trusted with that ownership.

So that's one. Two is you do it in a DevOps way, and I don't just mean you slap some DevOps lipstick on it, and I don't just mean you bought a CI tool and you, you started quote using the CI tool. You basically follow these concepts that DevOps is, is sort of, uh, put forward the three ways of DevOps.

They're called, um, flow, which has now actually been renamed. Uh, it was always originally this systems thinking, but flow is shorter. So I think, uh, gene Kim originally went with flow, but, uh, basically flow and, and, and systems thinking are to think holistically about the risk of the overall system and the work you could do in the overall system feedback, rapid feedback, uh, in context feedback, rich feedback, um, and a culture of experimentational learning.

So try things and measure how effective they were and then adjust based on that. I don't just go with the policy manual as a, like a dead document that is out there or trusting some third party list, like open Sam or, or the o os list, uh, uh, framework or, or PCI or whatever. Basically learn and, and adapt and evolve.

And if you do this, you come up with what I call practices. Um, oh, by the way, before I move on, the third thing here on this, on this page is never forget that you're building software. Uh, you know, and that's the, that's the value that the software engineering folks provide to the organization.

And that's the bottom line. Um, it's, it's, it's DevSecOps. It's not SEC DevOps, it's not ops sec dev, it's DevSecOps.

It's, it's you, you, you really have to produce a product. And, and anything you do that slows that down, it better be slowing it down temporarily and speeding it up later. And this, this is the way to do it.

So these are the practices. This is an example list of practices that, um, a a company who is engaged with me to help them develop this program to, to adopt this program. Um, this transformation blueprint, if you will, um, might come up with, and I say, might come up with an example, because I don't want you to simply adopt this one, but I'm gonna use this one as an example to describe what a really good set of practices actually looks like and, and what the characteristics of that are.

And even some of the specifics of the way that the, the, um, um, practices are defined here. I'm gonna talk aloud a little bit. So when I do these workshops to help teams develop their own list, they come up roughly similar, maybe two thirds, three quarters the same in terms of the things that are on the list.

And the weightings can be more different than that. Um, but, but, but, so this is a good representative senate list. So let's talk about the characteristics that makes this list, um, important.

So it starts with non-security engineering practices, and there's a couple reasons for this. First of all, the, it's not all of the SDLC defined here. It's just four practices from a robust DevOps SDLC.

Um, it's the ones that will make it easier to efficiently and effectively do the security things later that I'm highlighting here. And they're the ones that if you're missing these, you can't do it the optimal way. And so what the tendency of security leaders are is I need a least common denominator policy or set of practices that will work for even the teams that aren't doing great engineering.

But my argument is, you can't have great security without great engineering, and you gotta advocate for some minimally great engineering if you're really gonna ever do security effectively. And, and I think it's important for you to be, that's, that's the first reason. The second reason is if you come out as an advocate for great engineering, you, you put yourself in a different light security people put themself in a different light to the engineering people.

And, and that builds the relationship. And a lot of this is psychology and sociology. And, and then that's the key to the difference between success and failure of rolling out a program like this.

And so this is one of those things that you do that sort of, uh, helps with that psychology, uh, aspect of it, sociology aspect of it. Um, so I've got, you know, working agreements. I've got ephemeral build to test infrastructure.

So you know that, that a lot of people have that they bought it. Um, how well are they using it? For instance, can they stand up a database in the test infrastructure ephemerally and populate it with enough data to run automated tests?

If they can't do that, they're not really effectively gonna get the DevOps benefits that are advertised from DevOps. It it, it's this whole idea of cloud data providing you with this ability to just instantly stand up of virtual environment. Now, there's a lot of engineering work that has to go in to making this transition from adding a dedicated test environment to having an ephemeral one, including databases and message buses and, and data in those databases.

And so this is what I'm calling out here is, is that work that needs to get done, do that. And then, um, are you running tests in this ephemerally a single test that gates on the poll request is like, is like worth a ton because soon as you get a single test, then you start to get more tests. And, and anytime we implemented this at Comcast, help someone implement this effectively a Comcast, um, within six months, they had 80% test coverage run in the, uh, in the pipeline, uh, most of the time.

I mean, not every, not every time. Um, and then getting to that 80% level is also important as well. So those are the three, the four that I call out.

Um, for, for pre-engineering practices. Um, there's prioritization which enables gamification. So there's a waiting on these things.

So the, the order is generally in the order of dependencies, like you have to do this one before you do this one. Um, and then the, the weighting is based on sort of the value, the risk reduction value. It might reply it, it might, it might, uh, provide, um, or maybe it's the value, the portion of the value that's sort of pre-work versus the later risk reduction value.

So it's not, it's not, it's not science, it's, it's sort of like, um, psychology, we're gonna put these many points on doing this thing and, and then you're gonna gamify it. And, and by gamify it, I mean you have a leaderboard for each development team. You know, when they adopt a practice, then they have, they get that many points, improvement points, and the leaderboard for the teams with the most improved scores in the last 90 days are on the leaderboard.

And, and the ones with the absolute highest overall scores are, are on a different leaderboard. And you emphasize that the improvement leaderboard the least at first, but maybe even indefinitely. And then the absolute one is just to sort of reward people who got there and finished the program and, and are continuing to slightly improve after, after that, um, uh, gamification.

There's a lot more to that. I don't have time to go into all that today, but it's really key and it's, it's really important to, to, to do it. Um, you get no points for running scanning tools.

You get no points for finding vulnerabilities that is of zero value. In fact, it's probably of net negative value. You only get points if you get to clean for some small slice of the findings.

And the small slices are risk prioritized. So you, so we have here critical clean for third party code you import. So this is SCA, this is open source vulnerabilities.

It's just open source vulnerabilities. It's not SQL injections that your own developers wrote. And it's just the criticals and that's worth 12 points.

And uh, it's, it, it's worth 12 points for critical clean for the code. You write vulnerabilities, the first party code, vulnerable SQL injections and cross site scriptings that your own developers have injected in there. And then you start to work on the highs and they're worth less points.

And then I don't even list the mediums on, on this, on this example here, but you could and, and, and get assign points to them. Um, so it's this idea that you get and stay clean and, and clean involves putting a blocker in place so that you can't ever release with criticals. Once you get criticals clean, you never release with criticals ever again after that.

And that's how you get to this less than one day MTT r that I spoke about earlier. Um, so how do you, um, uh, how do you sort of organize this? Well, it's gotta be sliced pretty thin.

So, so it's gotta have a shallow on-ramp. That's why I separate criticals from highs, and that's why I separate first party code and third party code because I wanna give people something they can achieve in 90 days and get and completely accomplish and, and consider that done and never fall back on again. It, and it has to be small enough that they don't feel like it's too daunting.

And then, and then we move on. In fact, I, when in practice you'll slice the, you, you might slice this even smaller. If there's a hundred eyes and they don't think they can get it done in 90 days, then you might say, okay, that's fine.

Uh, you know, you've got all the criticals, you have less than one day MTTR for all the criticals going forward. You have, um, highs with the, the first five of the OS top 10 or the first 12 of the O sands top 20. And you slice it, even, even, even, um, narrower than that, that shallow on rent is really important.

Okay, so how do you get this list? Well, here are the critical elements to hosting a workshop. And I host these, um, I as my job at, at at contrast.

Um, uh, I do, I do these a lot. I do these publicly. I do these with a just your organization.

Um, but the critical elements, uh, are this, first of all, you have to have the engineering leaders in the room, the three to five most respected engineering leaders in the room. It can't just be the CTO or the VP of engineering. If they aren't actively working with code every day, they're maybe at a touch.

Um, maybe they're invited, but you gotta also have, um, some of the hands-on, uh, folks as well. In fact, it should be dominated by those hands-on folks. It's typically the team leads of the, of the hottest products, the, the crown jewel products that you're at your, at your organizations.

These are the ones that have the best tools and the, the best teams and everyone wishes they could be like, uh, these guys and listens to them, looks up to them. Um, why do you have these people in the room? Two reasons.

First of all, you'll come out with a better list of practices, uh, this way, uh, you know, so that's the sort of the obvious reason. But the more important and the more subtle reason though is that you're starting the sales process here. So if you were to just come out as a security leadership group, come out with a new policy or a new set of practices and say, here, you have to do this, they're likely to ignore it.

And, and they're gonna, the, the decision to ignore it is going to be basically they're gonna go to these three to five most respected people. They're gonna say, Hey, you know, is this just another one of those things we can just sort of let die and, and and not actually listen much to unless we get, you know, harassed with it and or do we, should we really adopt this? And, and they can say, I was in the room when we, we created that.

These three to five leaders are gonna say, and, and it is really good. It is really the right way to do security. The developer or the engineering way to do security, not the security way to do security.

And I was there to help make sure that was the case. Now if you pre-draft it, that doesn't happen. And so you gotta enter the room with a blank slate and you can have it in your head, right?

You know, what you think should be on the list if you're a security leader. Um, but you gotta, you, you gotta not bring a draft of the practice list into the room. You have to create it with post-it notes.

And the reason for that is that you get more, you don't get sort of group think that way where one person says something, everyone goes, yeah, that's pretty good. I don't really feel like arguing why it's not perfect and I'll just roll with it. And you don't want that to happen.

You get everyone to work independently, like just one person coming up with their own five favorite practices and then you have them all put them up on the board and you organize them. And that way you don't get any group think and you get everyone's wording is different. The terminology usage is different.

And you get the conversations as you start to do the grouping. And, and that's where all the magic happens. That's where the great practice list comes out of, out of that, um, you end up with this mindset shifting.

These conversations lead to mindset shifting and blind spot revealing, um, alignment. And, and that is hugely value. That's probably the most valuable aspect of hosting this workshop.

You also get this weighted list of practices, uh, and then, and then it's written in language that is, uh, acceptable to, and a well understood by isn't ambiguous to a developer. I remember, you know, there was a policy that talked about known vulnerabilities and I asked people in the security group who wrote the policy manual, what was meant by known vulnerabilities and they had different answers. And so then you went to the developers and you asked them and they had different answers.

And so how do you actually enforce a policy if you, you have ambiguity of terms. Um, so you don't use that phrase, uh, or if you do, you define it clearly there, and that's an example, but there's a lot of things like break the build happens a lot. Like what does that actually mean?

Break the build. And, and, and so you, you have to actually define these things more carefully, um, and use language that's explicit and, and really gets it accurately, right? Um, you don't just say the workshop's over and we're done.

This is a living and breathing thing. And, and in particular the first couple weeks afterwards, you're testing this list out by coaching teams. We'll talk about coaching here briefly for a minute.

'cause I'm, I'm running out of time here. Um, uh, with real pokes. And then you keep, um, having to, uh, sort of tweak it over time.

Maybe, maybe you get to the point where you don't change the list itself or the waitings, but once a year, which is the point we got to at Comcast, but you're tweaking the, the documentation that's behind the bulleted list of practices all the time, you know, with examples and links to architectural, um, uh, uh, security architecture, um, working code, uh, libraries, et cetera. All of that gets built out, uh, over time and get constantly gets, gets tweaked. So you have this list of practices 'cause you hosted this workshop, um, you tested it out briefly.

How do you actually roll it out? Well, you roll it out with coaching. And coaches are not necessarily security experts, just like Ted Lasso was not a soccer expert when he went to go coach a soccer team.

He was an American football expert, um, expected to fail, but, but Ted didn't fail because he knew about getting more out of people, getting, getting them to work well together. And that's the role of the coach. It's very hard to get people who have been doing vulnerability management to step into this role effectively.

They're used to calling someone's baby ugly all day. They're used to the people who you're, they're speaking to are used to being, uh, talk to them by them as either babies ugly, their baby's ugly all day. It's very hard to get that trusting coaching relationship going there.

I hired Scrum masters. The first few roles that filled this, I later actually hired an auditor and, and a few other different types across the organization. Some of which you could argue were doing vulnerability management, but that was later in the program when, when it became clear sort of, uh, they even realized that the way they had been doing vulnerability management was destructive and not productive and the new way that I was sort of pushing to place theirs, um, and their jobs were going away.

Some of those people did come over and become coaches at, at Comcast. Um, one of the principles of coaching is that there are no red marks for the current state of maturity, the current adoption rate. Um, the only thing you get dinged for is failure to improve.

You are not even trying. Um, and you get this commitment from engineering leadership upfront when you start to roll the program out. We are gonna ask every team to adopt one to three of these practices every 90 days.

So it takes about a year and a half to adopt all of 'em if they starting from zero. Um, but, um, are you okay with that? Will you help us advertise that?

Will you, will you set that expectation that they, you know, even if it takes away a little velocity from feature work, they are to adopt one to three of these practices every 90 days. Um, and, and that's all you get dinged for is if you fail to improve in a given 90 day period below a certain threshold, once you get to, you know, 80% or of the points, then it stops to be, um, something you would even get dinged for for failure approved. 'cause you know, it's harder that last 20 and they're less valuable that last 20.

Um, okay, so, uh, I don't have time now to go into detail of the coaching, um, philosophy a little bit, but, but as, as well thought out. And so let's just move through these slides quickly. Um, notice there's no red marks for the adoption maturity.

It's just shades of green. We had red, Amber Green and we found that people were tendency to lie when there was amber or green or red on the, on the board. So we just shifted it to shades of green.

Um, you host workshops as coaches to, to do this and, and there's some key people that have to be in the room. The business people have to be in the room to do them. And there's a process for hosting the workshops.

There's some tooling you can use. And so one of my open source projects is called transformation Do Dev Blueprint. dev and sign up for beta if you want.

Um, but it has this way to put in this list of practices and a way to sort of host the coaching sessions and a way to visualize the output. Um, and this is sort of example, screenshots for an earlier version, uh, of that. Um, you have to co-teach in team individually.

You can't do it say all of engineering. We're gonna just say all of you have adopted this practice because it doesn't work that way even within a single business unit. You know, two sister teams that work closely together can have very different maturity and tech stacks and the whole nine yards.

Um, and so the first answer I get, objection I get to this, is it doesn't scale. It scales beautifully because this coaching model is very much workshop driven and they're 90 minutes for the first one and 60 minutes for the follow once, and you only owe them once every 90 days. So a single coach can handle, uh, theoretically a hundred teams at Comcast.

We typically, once they got above 75, we started hiring new coaches to get that back down again. Um, so we never had anyone consistently be above a hundred teams that they were, they were in their domain. But, but, but we got, you know, in the 75 to a hundred range for everybody.

We tried to stay in that sort of sort of range and it worked. They had enough enough time to pay attention to to those teams and keep them going with that. And different teams are at different stages in the process.

So they, you know, when they're a year into the program and they've done four quarterly workshops, they pretty much know the routine and they can do a lot of it on their own and sort of move. Um, I mentioned transformation Blueprint. I'm gonna mention, uh, contrast.

When I left Comcast, I, uh, had a choice where to go. I, uh, all the tool vendors, we had a dozen sort of tool vendors, all the, the, the top names, SAS vendors you can think of like checkbox and VER code and, and AppScan and, and Verity and, and you name it, we had it. Um, and contrast.

And, um, I chose contrast. I got job offers from most of them. I cos contrast because teams at Comcast that had been using Contrast were the most successful.

Um, and, and um, so I wanted to come to a company that basically fit with that vibe. Um, I don't have too much time to go into sort of what contrast is, but it's basically one agent based tool, very much like an a PM agent except you mo you use it, um, pre-prod for most people most of the time. So it's not just runtime in production, it's runtime, um, during testing.

And that's why automated testing is so important, um, to use to, to have not just for quality reasons, but for security reasons. So you can replace your SAST and DAST and SCA tools, um, but it also has production, sort of oriented things. We can block attacks, um, and we can give you, you know, the blast radius for an attack.

And we can also give you a reverse engineered security blueprint for an attack going on. Uh, what databases are involved and what kind of data are in this databases. Um, so we have all these different things in our product.

It's a great fit for this model that I just described. Um, so that's all I have for you today. Um, please, uh, hit me up for questions.

Connect with me on LinkedIn and send them directly. Um, I, you can also ask for a demo there, um, or even ask to schedule a transformation workshop. There's no charge for that first workshop.

Um, uh, it's half day or spread out over a week. Um, and I do these all the time for people that maybe don't even buy contrast in the end. Um, although a lot of 'em do.

So that's why we continue to offer it for free, uh, to, to prospects, uh, for, for contrast then, and they continue to pay me, uh, to work there. So thank you.