00:00:04

My name is, uh, John Melton. That's my Twitter handle. If you would like to reach out and ask me questions about all this. Um, later on I'll talk a little bit about some tools, um, that'll be accessible in GitHub if you are interested. Um, I do have to take a flight pretty soon after this talk, uh, but I really deeply enjoy talking about all this. Um, so if you'd like to chat, I'm more than open to that. I'll hang out for a few minutes. Um, but don't think less of me if I, if I kind of hustle off so I can catch a plane. Um, alright. So I am the AppSec lead at, uh, company that Oracle bought called NetSuite. We are A-E-R-P-C-R-M type company. Um, those are kind of the stats about, uh, 5,000 employees, about 1200 developers that I'm responsible for. Um, so I have done dev and security work.

00:00:55

I've kind of gone back and forth. This talk is about security and moving it, uh, into DevOps environments. Um, but I've done this at a few different companies and on the side I kind of do quite a bit of stuff with oasp. Everybody know oasp? Awesome. This is the right crowd. Fantastic. Uh, so I'm the project lead for app sensor at oasp. And the tool that I'll talk about today is manna, but I've been with Opsp since the very beginning. Um, and then the kind of standard boil look plate. So this is about 30 minute talk. Um, I think the standard suggestion is to cover 20 to 30 slides. This deck is a hundred, so you are not going to pick up everything off these slides. Please go grab them and look at them. I'm not going to talk about every point. I'm gonna try to hit the highlights and, uh, hopefully get you thinking.

00:01:46

Thank you so much for being here. There's really interesting talks going on right now. Some I'd probably rather be at than my own. Uh, so thanks for showing up. This is gonna be an honest retrospective. So it's about two years of work that I've packed into this one deck. And I'm gonna be very upfront and honest about what worked and what didn't work. Again, I think I've heard all balls quote of context is everything quoted a few times at this conference. This is my situation. It's not necessarily gonna be yours, but you could, should be able to pull some immediate applicability, uh, and be able to move forward. And then I'm going to hopefully give you some bullet points of what I would try to do if I had to do over again, which, uh, actually I do because I'm doing it at the parent company of where I started.

00:02:33

So when Jean asked me to come give this talk, um, I kind of went to the website and said, what is this conference? 'cause I'd honestly not heard of it. Um, and had a bit of imposter syndrome. So, um, I decided to go to the story approach because you all are very, very smart and, but you can't really tell me what my story is. So I thought that was the only valid thing that I could really talk about that would actually work. So we're gonna take a story approach, um, and we're gonna do story time. So my goal is to essentially be this guy for you. If you don't remember this video, this is the guy who was teaching kids about gun safety and shot himself in the foot in the process. So I'm going to try to take this approach of I've messed up and I'm gonna tell you how I've messed up.

00:03:14

And hopefully you can avoid those lessons. Again, context matters. So depending on your perspective, depending on your environment, you're gonna get different things out of this talk. Or some of them you can throw away off the top. Hopefully some of them will be useful. This may be the most important slide to give you context. So I was working in an environment of a startup that was still very startup ish. Um, but it was about 15 years old at the time, but it still has the, the startup feel. There were no security people. So this is the environment I got dropped into. And the reason that I got dropped in was because that middle company, or I'm sorry, that middle, um, area there had acquired this company on the left. So the middle company is still technically a startup, but they'd been around about 20 years and they had much more of a traditional feel than a, uh, than the one on the left.

00:04:04

Uh, they had a full, full security team, but part of the agreement was you're not gonna impose your security processes on our environment. Culture was important. So we wanted to work through this. So they brought me in to deal with microservices and DevOps shop, um, because I'd been in that environment. So these were the stats and, and my job was basically to come in and get stuff done and I was the one person there. So these, these were my goals when I came in. I was gonna update all of these things, essentially prep for compliance because they were starting to expand into other markets and they had to deal with things they hadn't done before. Secure everything and basically do it in a DevOps compatible way. Uh, so the first day I thought, you know, I've got this, I've done this at companies before, it's gonna be easy.

00:04:46

Um, I came in, drank from the fire hose. Uh, so be humble. When you go into a new environment, don't think that you've got everything worked out. The first week was interesting 'cause I'm an engineer. So I came in and I started looking through code and I started seeing things that were not, you know, not perfect. Um, and then I started looking through process, documents and, uh, the lack of process documents sometimes. And, um, some of the stuff that had been around, you know, for a while. Um, so I have a few more of these. Um, I, I got to that phase and this is my favorite one 'cause this is the show I grew up on. Um, so I had a a a bit of, you know, I felt bad for myself at the end of the week. I was wor wondering about what I was supposed to do.

00:05:39

And then I came to this realization, um, right, that everything is okay. I came into a business that's operating, that's making money. They're being proactive about hiring a security person. So they wanna make things better. The business has run without me there. So I have to figure out how to, how to help the business be safer, but continue to run and continue to, um, continue to make money, right? Because if they're not making money, I don't have a paycheck. So my first quarter, this is, there's eight quarters, so hang with me. I'm gonna move pretty quickly through these. I'm first quarter, um, these were my proposed things that I was going to tackle. Um, just update training and get to know people. Everything was working great. I made a decent dent in the training. I found the right people, which I think is is critical to, to be talking to the right people.

00:06:30

Um, that was one of the more useful things that I did in the first one. So the, the second quarter was really in the first quarter was kind of a half quarter, so I didn't get a whole lot done. Second quarter. It's like, I know tech, I'm gonna get this tech stuff fixed, I'll have it knocked out six months in and then I can move to some other job, right? So, um, I had come from a company that built static analyzers. Everybody knows sas. Does anybody have, um, I should have asked this at the beginning. Anybody responsible for security at all? Sorry, it is super bright. There's like six hands. Awesome. Um, so I came from a SaaS product company before I took this job. So I knew sas. It's like I built one of these things before this pretty installing one and running it should be pretty easy.

00:07:16

Um, and then dependency analysis was another big thing. I I think a lot of the vendors out here would like to talk to you about this problem. Um, but it is a big issue and it's one that the security community had kind of honed in on at this point in time. So I was gonna, I was gonna solve those problems. Static analysis went okay. Um, I did a pretty decent job. A lot of that was owing to the fact that I talked to the developers and said, this is what I want to do. Tell me where to put it. Right? Um, I got nowhere on dynamic analysis, even though the tool is great. I just didn't have time. I then we did pretty good on the dependency analysis. Uh, we use an open source tool called Dependency check. Um, I'm happy to talk to people about commercial tools after this and what we use and what we like and my opinions.

00:07:59

I don't talk about that during the talk at all. Uh, but there's a few open source tools that I will, I will mention, I will point out from a security perspective, there's huge amounts of low hanging fruit here for dependency analysis. So if you're not doing dependency analysis, this is a really, really good place to start. And there's some easy wins there and, and you should definitely look at that. Oh, and, uh, sorry, did I click okay? Uh, updating training. I actually did worse because, you know, I made negative progress. 'cause I found out there was more to do than I actually thought I had to do. So the number one thing I wanted to point out here was, uh, tools might not be the right place to start, even though that's where I started, that was my comfort zone that may not, may not be the right place to start. The number one thing that I have learned of the last two years is, uh, an application inventory. So who has an application inventory, you know, all the applications that your company owns.

00:08:52

Wow, that is remarkable. Um, I've never had more than one hand go up on that, and I think that was a liar. So, um, application inventories are notoriously difficult to, to get in the first place and very, very hard to get right. Um, so whether you're talking about a static inventory and operational inventory, gluing that data together is really, really difficult. So if you're not thinking about this problem, uh, definitely a place to look. Q3. Uh, the main thing that I wanted to talk about here was credential storage and champion. So credential storage was an issue. We have hardcoded passwords, we have hardcoded keys, all that kind of thing directly in our source code or in some configuration files, environment settings, those types of things. We wanted to solve that. Uh, I like HashiCorp Vault here. Um, it's a, it's a really useful tool for solving this type of problem.

00:09:41

I'll point out how we did it later and give you some blog posts. You can go read lots of data. The Champions program, um, if you're not familiar with this, this is, it could be called lots of different things, but the security community tends to call it champions. Essentially what it is, is each scrum team has at least one person on the team that's responsible, more responsible for security. Um, so that gives the security team this window into what's going on in the dev environments. Gives the developer team responsibility over security things so they can control and manage and move quickly. So this follows the model of you set the requirements, right? So, um, one of the worst things for these team, uh, when you go into any organization is to say, ye shall do it this way, right? This is not particularly helpful because each team's gonna have their own needs.

00:10:26

So if you say you have to solve this class of problems, choose how you do it. If you wanna use our tooling from the security team, great. We'll help work with you and get it set up. Otherwise, you know, as long as you meet the requirement, we're there. So that's what champions really does. Uh, it also gives you, gives people an opportunity to grow their career. So if you want to expand in security, this is a great way to do it. Uh, one thing I didn't mention here on dynamic analysis, I had punted on this 'cause I couldn't get it done. Um, we had quite a lot of selenium testing and scripts and that kind of thing that were already being done with our QA team. And through this champions program, I found somebody who was really interested in security and I said, Hey, can you go take a look at this problem?

00:11:07

Like, I would really like to solve this problem. And he said, sure. And a quarter later he came back with, he had learned this tool that we wanted to use, which is zap, it's an open source tool from OAS for security testing, for dynamic analysis. Um, he had learned that he had integrated it. He had written a bunch of tooling and he had it queued up and it was running on our nightly builds for a particular application. So I did zero to make that happen. But through the security champions program, we got this going pretty quickly. So that was really helpful.

00:11:40

Um, and then I'm gonna make this point a little bit more emphatically later, but, um, leverage open source where possible contributing back is a big thing for us. And then also, uh, I was struggling with how to build these programs, but I have learned <laugh> that, uh, over and over again that people on GitHub, Twitter, wherever you are, those environments, if, if you kind of go in and say, Hey, I'm interested. You seem like a really smart person. Can you teach me about whatever people really like to talk about themselves? So they will communicate back with you and give you lots of information tools. I've had a number of people give me in access to internal tools just by asking the question. And, you know, we had this problem to solve. Alright, Q4, um, metrics, uh, this was a tire fire. Um, and then threat modeling and tracking attack service.

00:12:29

So let's talk about threat modeling. Um, so who in here does threat modeling, architecture design, reviews for security? That's about what I expected. Awesome. Uh, so two hands for those that didn't see that. So, threat modeling is essentially helping developers think about security when they're building an application or when they're designing an application, maybe is a better way to phrase it. So, uh, everybody talks about shifting left to solve more problems earlier. We know this time, and again, from all the research over bugs are much, much cheaper to fix in the design phase than in development test. Um, prod, same, same thing holds for security. So we should look at these issues there. Um, and then tracking attack service, this was another part, part and parcel to our application inventory, we didn't understand because we had so many microservices exactly what those things were exposing and we couldn't keep up.

00:13:20

So, you know, there's one, one person tracking a couple hundred developers, and that's basically the model for security. You have, uh, in the general open market, you have about one security person to every 200 developers, depending on the data set that you believe. Um, I don't know about you, but that's, I can't code review for 200 people. I mean, that's not my job, right? I can't do that all day, every day. Um, so the scale was an issue. So we, we had no way to figure that out. So we came up with something here for threat modeling. The thing that I would recommend is starting small <laugh>. So just get, um, we chose the stereotypical stride dread model, uh, but we did a super lightweight version of that. What we wanted was a diagram of what you were building and the data flows and that kind of thing.

00:14:07

Um, and then we wanted you to come up with a list of threats. We started, we gave you a starter list of threats. And importantly, when you think about threat modeling, there's, there's this, you can go down a rabbit trail really quickly, and there's this whole huge list of threats that you have to worry about. Um, most of those are canned, right? Um, if you talk about the OS top 10, most of those are gonna be canned, depending on your environment. So we don't ask people, are you worried about Xs? If you have a web app, we know you're worried about Xs. We ask people more. If you think about maybe fraud detections a better place to start. Think about how your application, the business logic of your application can be broken or abused in an interesting way. Um, so a helpful thing here is abuse cases in addition to use cases. So that was a good way for us to get people started thinking about that. And then tracking attack surface, uh, this was really helpful for us. What we did was, and I'll I'll point you to the tool later. Um,

00:15:03

We leverage the same thing that, you know, frameworks when they start up, we're using a set of frameworks when they start up, they have to know the routes that they're exposing because that's kind of their job. So we just hooked into that and said, okay, every time you spit out some endpoints that are accessible, we want to keep track of that. So we just really did it as a list and then we diff those files over time, right? So you might have to go out and buy the diff tool, uh, in order to support this. But, you know, pretty simple and straightforward. It's not perfect, but it gives us pretty, pretty good indication. Um,

00:15:40

All

00:15:40

Right, I think all these are good. Okay, so y'all are doing good. We're halfway done with the, uh, basic set. So we're gonna keep, keep chugging along. Um, sorry, that was funny.

00:15:53

Eh?

00:15:53

I'm doing okay. Um, so we got acquired at this point in time and, uh, the things that we started looking at now were containers, right? This was a couple years ago. We started looking at containers, runtime intelligence, and particularly the app deployment tool. So the things I learned here, the app deployment tool, I'll give you links to, and I'm not gonna talk too much about that, but essentially we were able to build quite a lot of safety into the app deployment tool. And from a security perspective, particularly if you have an operational, if you have a team of DevOps who is looking to optimize everything, everybody's looking to push down, right? Put more controls, put more things into my platform so that I as the developer, don't have to worry about it. That's the reason that we have sidecars, right? That's the reason we have these proxies that are doing this workforce.

00:16:38

That's the reason service messages are, are a thing. Now, because we wanna push things in the middleware, we wanna push things into proxies, that this is just a natural thing. We wanna have less and less responsibility on the application itself. So the same thing is true of security. So we can push all of that down into the deployment tool. It's much, much better. Um, for containers, uh, there's a, I think I've got a link to it in here. Uh, it's, it's aging now, uh, but surprisingly a lot of the information's still relevant. Um, it was written by the NCC group, Aaron Re, so if you're worried about securing containers, that's a good paper to go read. It's like a bible. It's about 130 pages, uh, really, really good. So we, we followed that and I was lucky because we were doing green greenfield containers. I recognize some of y'all are not, um, but there's a lot of primitives and containers that gave us a really, really easy path. And as long as I figured out the, the few bumps along the way, um, we were able to set some really good defaults for containers. And that gave us a huge boost on security.

00:17:36

Um, so I'll, I'll point out really quickly here. Sorry. Uh, runtime intelligence, the idea here, you can go look up the app sensor project. That's what that's all about. But essentially the idea is that you can build, you know, fraud detection for lack of a better term, into your application themselves and build something called self defending application. So applications can track what's happening to them. And if you have a situation where somebody's misusing your application, if you keep track of that, you can now start detecting attackers over time and not specifically attacks. You can start looking for, uh, terrible behavior going on in your applications.

00:18:14

Alright, so, um, and, and from a runtime perspective, AppSec and OPSEC is an area that's ripe for, uh, exploration and renovation. Uh, so these are a couple of, uh, blog posts about the tooling that we built for operational deployment and how we baked security in. So please go read those. Uh, the next thing that I wanted to, uh, point out was core security libraries. So we moved from a model of trying to tell everybody, Hey, this is broken, this is broken, this is broken, this is broken. You know, um, if anybody's familiar with dast or SAS or ias or rasp, any of the, that set of tools that come outta the security products community, um, most of them are, the way they work is you build an application, you get done with it, and we throw everything we have at it, and then we will hand you a PDF that's 7,000 pages long that says, here's all the broke stuff, go fix it.

00:19:05

Right? That's not helpful to anybody. And hopefully we all agree on that. Um, so we took the other route. We said, okay, here's the one paved path, the one right way to do this. And started small. And we gave them this is the right way to do it. And then we said, if you deviate now from our policy of this is the right way to do it, you may not be insecure, but you now a policy deviation. So, uh, by giving people this paved path, it helped with new recruits. They didn't have to guess anymore. Like, okay, I need to, I need an ORM framework. Which one is it? Well, it's this one, right? That's the only one that we use and that we support. So go to that one. Um, so some people from Netflix might disagree with this on the freedom and responsibility.

00:19:44

I know their security team well, so they would, they would argue this point. Uh, but it's been really helpful for us. So we did, uh, well with this, uh, one helpful thing there is to, to go in and write, um, custom rules matching things to make sure that people are actually doing this properly. And then, uh, from my perspective, if you're in security work, um, you should stop worrying about killing bugs and start worrying about killing bug classes. Uh, that's where the interesting engineering work is. So if you, uh, there's a great paper at the end of this talk, uh, from Google where they talk about, they made a couple of bug classes obsolete at Google just by spending a year's worth of a, a man year's worth of engineering effort. And when you think about the, the amount of engineering effort going in at Google, a man year is trivial, right?

00:20:30

That's a rounding area. So they, they were able to solve some of these problems in interesting ways, good paper degree. Okay? Uh, couple of final things. Uh, immutable infrastructure. Uh, this was a big win for us by saying, you're going to, you're not going to undo something, we're not gonna roll things back. We're just gonna roll over top of them. We push forward, we make sure the infrastructure is not tweakable. If you want to get new code out there, you push a change to the commit or you commit a change to the repository and it runs through the same process. This was really helpful for us. Kept people out of tinkering and production and causing snowflakes. Uh, the other thing is fast and slow checks. Um, we split our pipeline from, we want to block the build in some cases, but in very, very, very few cases.

00:21:16

Um, and so we put the things that were super fast checks, which a friend of mine refers to as the GR master 5,000, um, which is the super fast things that you can check and get off the list. Uh, and what I refer to as, you must be this high enough to ride. Um, so as long as you can pass the basics and there's lots of things that fit in this bucket, uh, if you just start thinking about 'em, then you can split off your, find the pile of bugs at the end, uh, in a separate asynchronous process. And so that was really, really helpful for us.

00:21:49

Um, config configuration management, infrastructure management tools turned out to be really, really powerful, um, for security, particularly because it now gives us, um, an environment that we can interrogate to find out the infrastructure, um, state. Alright, and then the last one we're gonna talk about is, uh, the application portfolio. So we stink at this. Uh, just being honest, uh, it's a really, really hard problem, particularly when you're at a company that has evolved over time and you have lots of different, you know, I mean, we have all sorts of different VCS systems, we have different CI systems, we have different ways, you know, we've got 37, um, you know, Excel spreadsheets that track this stuff in different ways. Uh, we have different clouds that we're deploying to. We have data centers. There's stuff all over the place and it's really hard to glue all that stuff into anything.

00:22:40

There's no vendors giving us a ton of help here, so this is really hard, hard problem. Um, so if any of you're very smart and wanna disrupt something, there you go. That's a, that's my best suggestion. Alright, so how did we do? Um, compliance was obscenely, <laugh>, obscenely time consuming. We did a pretty good job on that. We got a bunch of check boxes from different groups. Um, we were able to embed, we did a really good job, I think, with the champions program, so that was pretty helpful. Um, they did way more work than I did. A hundred people doing an hour of work a day is way more than I can accomplish in a week. Um, or an hour of work a week is way more than I can accomplish in a week. So spreading that out and, and giving people a path to do things that they're interested in is really helpful.

00:23:30

Excuse me. So, alright, so what can I offer to you to, uh, to go home with today? Um, so this is a lot. I'm not gonna touch on all of these things. I've talked through some of them, um, and I've got a lot of points and seven minutes left. So, uh, I'm gonna try to, I'm gonna try to hit the highlights. Uh, but please, please download this and, and look at it. Um, I would say if I was starting over the things that I would, or somebody was starting in a position doing the same thing, I would say focus on champions and say no, rarely. 'cause it's not particularly helpful to come in and be the historical, um, who in here has a poor opinion of historical security teams?

00:24:13

Okay. Um, the rest of you are liars, um, <laugh>. So saying no is not particularly helpful, uh, that, that shows you how immature security is and that they don't. Um, we as a field don't really understand that the business has to operate, right? Um, saying no rarely also helps when you do have to say no, people trust you, that you're not making something up, right? That it's actually an issue. The other thing I wanted to say was, if you talk to people, I found this more and more if you talk, people are more interested because news stories are coming out. If you talk to people just about general security topics day-to-Day life, how do you, you know, what, how do I, how do I safely do online banking? Okay, that's, that's trivial for people in security, but it's really helpful. It helps you find friends that helps you find people that are interested in security. Um, there's a site there, security planner.org, which is really helpful. So if you have, if you are, um, you know, uh, non-IT related, friends and family need a place to go, that's a really, really great, um, site that can, can help them, uh, for process.

00:25:19

To me, this is all about building relationships with other teams. Um, security doesn't tend to be great about this, but making yourself accessible, uh, building relationships with under, with other teams, and then understanding the SDLC of the individual group that you're integrating with. Knowing what touch points you can hit, what touch points you can't, uh, where you're gonna be blocking, where you're gonna, um, cause problems. And then understand the business impact of that particular application. Because you may have a great security, uh, a great team who's really, really interested in security, and at the end of the day, their app just really doesn't matter to the business. Well, I mean, okay, you, we have to work with the apps that matter to the business. Um, from technology's perspective, you know, these are, uh, I think things that I, that I talked about quite a bit.

00:26:04

Um, but the two things that I think I would point out here is to focus on the big things. Um, there are things that matter more than others. So cloud is a, is a big enabler. It gives you a pro programmatically accessible environment when you can tell an environment to change and you can ask an environment about its state. You know, that's, that's game changing from security's perspective. And then the other thing is, uh, to support your primary tech stacks well. Um, so again, with Netflix, um, their model being freedom and responsibility, yes, anybody can use anything, but they do have a few tech stacks that they support really, really well. And so if you start with those, I happen to know from their security team, if you start with those tech stacks, most of the stuff happens for you. It's just automatic. If you go off the paved path, you can do that.

00:26:50

You have the freedom to, but now you have the responsibility to find your own tools to, to meet all those other security criteria. So it actually turns out to be easier to work with those, um, lots and lots and lots of homework. So please download these links. They're really, really great. Uh, that second link there is the Google talk that I, I talked about. The first one, if you are interested in, uh, doing security program management. Uh, Ryan McGann's been around for a long time. He's got a great series there. Um, so yeah, let's try to, let's try to get to the end here. Everybody knows this, I believe. Yes. Uh, really old thing that's gotten resurrected, um, where people talk about the things that they fundamentally believe is core truth. So I wouldn't put this in that bucket, but these are things that I think out of this talk that hopefully you take away with you. Five things.

00:27:39

If you're a security person and you can't code, um, you should learn how to code or you should hire people on your team that know how to code. This is endemic in the security profession and it's a problem. Uh, this is the reason that I only hire developers. I don't hire security people anymore. We know enough about security. Developers need to know how to code. If you're gonna make an impact, you need to know how to code. We obviously don't scale effectively. So you have to build a champions program and build your application or your security capabilities to be self-service. So the Champions program helps you with the people problems and self-service helps you with the technology stack. Uh, we should look at more detection and response. This is something that obviously all of you in this room know. Um, but security really only talks about prevention.

00:28:20

They don't talk about, okay, you know, I put this control in place. How do I make sure that that control is working? So we need to get there. Obviously we, some of these things matter more than others. Uh, if you put in CICD automation, it matters way more than if you put in a grip check for some, you know, API call. So we can, we can make a bigger difference and we should focus on those. And you can't protect what you don't know. You should build an app inventory. Alright, so we're almost done. Um, this is my personal belief that you should be contributing back to open source. Um, I'm not going to ask, but I believe all of you are using open source based on the talks that I've heard earlier. Um, so most of us are probably in organizations or, or personally can give back.

00:29:00

Um, so there's lots of ways to give back to open source. You can write stories. Stories are super helpful. If I had more stories about what didn't work, I would've done some things differently. So that would be really helpful. Uh, code is great. Documentation is great. Um, any anything you can give even mentoring is a huge thing. Um, so there's this project, uh, I won't, I won't belabor the point, but essentially this is a, um, it's a security scanner that works on GitHub that is open source that you can go pull security scanner that works on GitHub that has exactly one rule, which is not great, but I grant you, but it does something right? And so, uh, it finds this one really weird esoteric static analysis bug. But the point is, is that if you think about this one bug, I don't know how many times this thing has happened across, um, across all of GitHub, but if you could fix one problem across all of GitHub, how useful would that be, right?

00:29:53

So if you start thinking about how do you scale out your efforts, uh, really helpful. Um, so there's lots of different ways to contribute. Again, I believe that y'all can do it. Uh, it's open source. Uh, that's your homework. And yeah, hard to say goodbye is what that's from, by the way. Uh, that's it. And since I'm from the South Charlotte, uh, where ING's a big thing, I don't think we have time for questions, but I can't not put that slide in. It's in all my decks now. So, um, again, I'll, I'm gonna scoot outta here fairly quickly, but I have about 15 or 20 minutes if anybody has questions. If not, just reach out to me please. Uh, I enjoy talking about all this stuff, so thank y'all.