Press Release
Governance, Risk, and Compliance (GRC) platforms can be very tricky to construct. Today, we sat down with an expert in this field to talk about building and deploying secure applications in the cloud. There has been a huge shift to this in recent years, to get his insight on how this is possible. Â
This episode features Jeff Schlauder, Information Security Executive, from Catalina Worldwide, who provides answers and explanations to a variety of questions regarding deploying applications securely in the cloud, using AWS (amazon web services), and much more.Â
Join us as we discuss:
- Â Â Â Building and deploying secure applications in the cloud
- Â Â Â The Logistics of Web Applications
- Â Â Â Building, operating, and maintaining secure Cloud applications
- Â Â Â Containerized vs Not-containerized applicationsÂ
- Â Â Â How to keep applications deployed secure
To hear this episode, and many more like it, we would encourage you to subscribe to the Virtual CISO Podcast on our YouTube here.
To Stay up to date with the newest podcast releases, follow us on LinkedIn here.
Listening on a desktop & can’t see the links? Just search for The Virtual CISO Podcast in your favorite podcast player.
See Below for the full transcription of this Episode!Â
Speaker Intro (00:05):
Listening to the Virtual CSO podcast, providing the best insight on information security and security it advice to business leaders everywhere.
John Verry (00:19):
Uh, hey there, and welcome to yet another episode of the Virtual CSO podcast, uh, with you as always, John Very, your host, and with me today, Jeff Slo. Hey, Jeff.
Jeff Schlauder (00:30):
Hey, John. How are you?
John Verry (00:32):
I am, I am doing good, sir. How about yourself?
Jeff Schlauder (00:35):
Good. Good. Yeah, I bourbon this morning, so I’m in pretty good shape.
John Verry (00:40):
<laugh>, you’re just reminding me that I don’t have a bourbon in my hand, Jeff, so we’re off to a bad start. All right. Well, so now you led perfectly into the first question I typically ask, uh, what’s your drink of choice?
Jeff Schlauder (00:52):
Uh, red wine. Yeah.
John Verry (00:55):
Particular varietal or a blend?
Jeff Schlauder (00:58):
Uh, just a, a mall backer. A cab straight up.
John Verry (01:04):
Am my, uh, malak are not my favorite. There’s something to them, you know, that’s sort of that literacy flavor sometimes they have that I’m not crazy about. But I love a great cab. In fact, I’ve been drinking, my father-in-law loves cabs, but he only drinks a hundred percent Cabernet Sauvignon. So, and, and they have a, you know, a little bit more chocolate, a little bit more coffee, a little bit more oomph. Uh, so I’ve been, I’ve been drink my, the cabs that I’ve been drinked recently are a hundred percent cab, you know, cuz as you know, what, what is it once you only need to be at 75 to call it a cab or something like that?
Jeff Schlauder (01:38):
Well, my, I try to stay under $15 as well. I forgot to mention that part. So, <laugh>,
John Verry (01:43):
I’m, I do too. Most of my, most, most of mine are, most of my, I mean, I’ll, I’ll go 20, you know, if, if there’s a bottle I wanna try. But my, every my everyday drinkers are usually in that $15 range. And you can find some nice, uh, Chilean a hundred percent Cab. Cab. Yeah. Well,
Jeff Schlauder (01:58):
I’ll hit you up for
John Verry (01:58):
12, 13. All right. I’ll get it for you. It’s my father-in-law. He, he’s, he’s the smart guy. I’m, I’m just, uh, I just, I’m just a follower. Um, alright, so thanks for coming on. Um, wait, actually, I forgot to ask you the, the other question. Uh, uh, uh, what is it that you do every day? Sorry, man, I’m, I’m off my game today.
Jeff Schlauder (02:16):
No problem. I, we started with bourbon, so I thought that was a better start. Um, what do I do every day? Um, yeah, I mean, I run a, a software company, so we, you know, Catalina worldwide, um, focus on building secure, you know, enterprise level applications.
John Verry (02:33):
Uh, and full disclosure, uh, we partnered with Jeff. Uh, Jeff had, uh, has done some phenomenal work developing, uh, a GRC platform, uh, that he’s been working, uh, with us extensively to customize for our use. Uh, I, I think, I think he’s one of the best development teams that I’ve ever worked with. And, uh, you know, it’s been a, it’s been a fantastic partnership so far, so thank you for that.
Jeff Schlauder (02:55):
Yeah, I appreciate that.
John Verry (02:57):
Um, so what I wanna, you know, what I wanna chat about is, you know, we’ve seen, you know, such a high percentage of workloads and applications moving to the cloud over the last few years. Um, and I think when you look at the major cloud platforms like the AWS and the Azure, um, there’s a lot of complexity there. And we get a lot of questions about, you know, how do you deploy a secure application in the cloud? And now specifically, you have a lot of expertise in aws, and that’s where you’ve helped us deploy our, a lot of our infrastructure. Um, and we know that a high percentage of the breaches, you know, what do they say 90 plus percent of breaches are because of people’s misconfiguration of the cloud, not the cloud itself. So what I wanna chat about today, and this, I always ask these really easy sounding questions that are almost impossible to answer, so apologies. Um, but is there a simple framework that someone can use to design, deploy, and manage a web application in aws?
Jeff Schlauder (03:59):
No. Um, <laugh>,
John Verry (04:01):
That was, Yeah. Well, and, and thank, thank you for, Thank you for listening to today’s podcast, <laugh>. On our next podcast, we’ll have a smarter guest. <laugh>.
Jeff Schlauder (04:11):
So simple was kind of the key word there. I mean, there,
(04:14):
I, i, joking right, obviously, Yeah. There, there’s multiple ways to, to deploy applications securely to, um, to, you know, the cloud, right? In this case, you know, we are, you know, specifically in aws, um, you know, designing a solution there, there’s not a lot of out of the box, right? Where, you know, the easy button, um, to just follow these two or three steps and you’re, you’re gonna be, um, set that, that’s typically not what we see and certainly wasn’t how we got there. Um, so there are a lot of, it depends that, that, um, you know, come into play. Um, but I can speak to, you know, how we have found, um, an efficient, scalable process, the types of things that we use, the tools, the, um, practices to manage an environment to what we believe is a, um, highly secured level.
John Verry (05:06):
Yeah. And, and I agree with you. I, I think it depends is the right answer to 90% of security questions, right? Because if you don’t understand context, uh, you know, then, then you can’t answer a question. So, and I think understanding the, the, the what secure is, and understanding an application context, right, is probably the first thing that you’d start with. And that would, that would definitely go a long way towards beginning that process of, of figuring out, you know, what that architecture’s gonna look like and what services you’re gonna be leveraging, Correct?
Jeff Schlauder (05:36):
Yeah, that’s correct. And, and I mean, and there’s not really one size fits all. So it’s, it’s going to, we, you know, there’s decision points there on who’s gonna be managing the infrastructure, what that support team looks like, their knowledge. Um, there’s a lot of really great tools and capabilities, um, as you know, within aws. Uh, but they’re not necessarily simple. So it takes time to, to, to build knowledge in each of those areas. Um, so if at the end of the day, the, the, the team that’s supporting the application and supporting the infrastructure, um, doesn’t have the, the, the, the knowledge necessary to, um, manage it the way it was architected. That’s probably the biggest security, um, risk, right? Is, is, you know, while we typically say code and, um, you know, as being, you know, the primary, um, vulnerability, I, in some cases, you can design a really, and we’ve seen it happen where you can design a really great, secure solution, but it’s so complex that a mistake or not understanding, um, how everything inter relates, um, can cause, you know, just unnecessary risk and ultimately, you know, security issues.
John Verry (06:52):
That’s really interesting. And, and frankly, I hadn’t thought of it in that exact context prior. And, and that speaks to there being a, a risk to the model many people use, because so many people outsource their development with the expectation that they’re going to be managing it themselves once the development is done. But if the entity doing the development isn’t thinking about it in the context that you just talked about, they’re handing off an application that people, you know, they’re handing the keys over to a, a, a fighter jet and, and these folks know how to drive a paddle boat.
Jeff Schlauder (07:28):
Yeah, I, I agree. I mean, it, it goes down to, you know, even the most fundamental things of key management and rotation, and now where the, um, you know, how you’re managing the secrets and these types of things. So if you know that you’re going to be deploying that application into an AWS environment, there’s certainly services there that you would use out of the gate versus, you know, building a, um, a portable container that may, you know, deploy to, um, multiple, you know, either on-prem or multiple cloud, uh, platforms. Um, so it really does depend.
John Verry (08:03):
Do you get into a situation where, um, let’s say, let’s say an organization has a very limited skillset, you know, that, that you’re going to hand this off to, you know, you may end up in a situation where you’re architecting to what they can support, but it’s a compromise solution. You know, So do you sometimes end up in a position where you, you, you, you pick the lowest possible common denominator, but it’s got to be where there may be, have to up their game a little bit. You know, like that driving that paddle boat around isn’t enough. You need to get to a, you know, two seed Cessna, um, you know, and you, and you, you’re going to have to get them to upgrade their internal skillset, or the, the security and the usability or the efficiency and effectiveness of the application could be compromised a bit.
Jeff Schlauder (08:53):
Uh, yes. I mean, that is certainly a consideration. We’ve seen it happen. There are ways to, even for the lowest common denominator to build a, you know, small, um, web app, a single page app, um, type of, uh, architecture in easy to manage, um, uh, solution like, uh, light sale, um, doesn’t require a lot of knowledge. Um, it’s not going to give you, you know, the scalability for an enterprise, you know, level global application, but has, you know, built in low balance or capabilities and, um, networking. So there are ways to do that, uh, you know, to to, to be able to hand it off to somebody who really doesn’t, um, have a, a comprehensive knowledge of how aws, um, services work in Interate. Um, but yeah, in, in most cases, uh, you know, deciding, um, when we start, you know, building an application, what the, uh, the, the vision is.
(09:53):
So where is it going to be used? Um, does it need to be, uh, you know, are we gonna go down the containerization road? Which I would say, you know, 95% of the time the answer is yes. Um, where do they, you know, how many are we deploying and having to support, um, you know, uh, Google Cloud as well as, you know, AWS and Azure, and where, what’s the and on-prem solutions? So some of these things, not necessarily for the code itself, but the whole process. So when we build an application, we’re looking at it from the actual lines of code to the pipelines that need to be built, the deployment process, the, the, the code reviewing, just kind of soup to nuts the entire process, and then trying to understand what pieces we’re responsible for and what the customer wants to, uh, take responsibility for.
John Verry (10:48):
Yeah. You know, that is that, do you find that, that your approach, and you took that approach with us, right? You know, like when we asked you, we came to you and we said, Hey, we want to do this. You know, you came back with numbers that were high, you know, and I was like, Wow, this is, you know, and you were like, Well, look who is gonna be responsible? It’s one thing to build something, it’s another thing to operate at maintain it, right? So, I mean, you’re thinking full life cycle, which I think, you know, was, was eye opening to me, and something that I was appreciative once I understood it. Um, do, do you think that’s, I mean, it seems to me like, like all too often you hear like there’s a differentiation between building it and operating it, and that’s part of that place where people can get themselves in trouble.
Jeff Schlauder (11:30):
Yeah. And I think that, you know, there’s a, I think a common misperception that just having somebody build it and then you’ll run it will somehow, you know, end up with a, you know, more secure application or less cost. And, and that just typically in our experience isn’t the case. Um, you can, if I’m building an application and handing that off, um, kind of as a, as a a one time deal and, and providing it to the, the company, I’m gonna charge more outta the gate, hands down. Um, but what I would charge at that point, maybe the same as operating it for two or three years, right? Combined together, because we would design it in a way that we, um, God, we, we look at it as like a paved road approach. If we’re going to build this and we’re going to manage it, we’re gonna build it using the technologies that we’re comfortable with, that we have, you know, not just experience in, but are kind of industry best practices.
(12:27):
Um, when we start introducing customizations or unsure of, you know, the, the, the full life cycle of the, of the application from development to, you know, um, full production maturity, it, it introduces, you know, risk. So we start getting a little bit more gravel on the road and a little bit more, um, you know, each customization brings risk with it. So our approach of following kind of our paved road of here’s what we do, and if we do it this way, it can actually, it may end up being less expensive to build it and operate it, then it would be for, to take a set of requirements from a customer and build from scratch and hand that back off. Um, that’s kind of how we look at it. So us truly understanding what the goal is, and it, do we have a, uh, you know, do we want to develop the relationship where we’re part of, you know, the, the operationalized fully deployed application or not?
John Verry (13:26):
Yeah. So I like the way you said, you know, what the goals are. What, what are the objectives? So what are, you know, like, so I’m imagining the, you know, the, the business requirements. I’m imagining their, their technical requirements. I’m imagining the types of data risk. What, what are some of the inputs that you’re typically looking at? You know, so that way you can make a good determination on, you know, make on these decisions that you’re making, right?
Jeff Schlauder (13:48):
Yeah. Some of our, um, I mean, certainly the, you know, there’s one design, you know, kind of architectural approach for a, a mom and pop, you know, eCommerce type of solution that, that, you know, has been, um, done a hundred times versus enterprise level global application and trying to understand the, um, compliance, um, frameworks that are in scope, um, the customers broader, um, uh, exposure. Um, you know, if it’s global, uh, those are certainly considerations. And it’s not that we would build it differently, it’s the rigor that goes into the process along the way. So where we’re automating certain gates verse having manual gates so you don’t have to build a pipeline and, um, and automate everything from beginning to end. Um, in every case, that may not be the right answer. And actually, even in the way that, you know, we manage most of our infrastructure, we don’t automate everything. Not that we couldn’t, but we, we, and even where we have, we, we stop and we have gating criteria, um, that, you know, allows us to really feel comfortable moving forward is the right thing to do, versus just pushing a button, deploying code, and, um, kind of running with that. That’s,
John Verry (15:17):
Yeah. They just become like sort of sanity checks in the, in the middle of a process, Right. You know, get some human eyeballs on, on something just to make sure that yes, this is going the way that we’re anticipating it’s going <laugh>,
Jeff Schlauder (15:27):
Right. Or insanity, just to confirm that we are truly
John Verry (15:31):
So
Jeff Schlauder (15:32):
Not crossing over into
John Verry (15:34):
<laugh>
Jeff Schlauder (15:35):
That
John Verry (15:35):
Is, Yeah. For some reason, I just had a shining a reference come into my head, but I won’t go there. Um, so, um, a quick question for you, cuz you mentioned it, and I think it’s one of those, one of those topics that, you know, people now are more and more familiar with the concept of containerization, but I don’t think they fully understand it. So like, if you were looking at an application, what would make you decide to have something be containerized versus not containerized?
Jeff Schlauder (16:06):
Um, it’s a good question. Um, if, if we’re taking our approach of, you know, how we manage, um, uh, our process, we would containerize it. Um, because we have, um, a lot more, uh, there’s automation as I mentioned, but we have, um, visibility earlier on into, um, risks or, uh, vulnerabilities, um, os related, you know, uh, challenges that may present after the code has been deployed to, let’s say an EC two instance. So when we think about, for, for us, um, you know, and everybody has their own opinion on this, right? It’s like bacon, there’s no, everybody has their own way that they, they like it and that some folks think, you know, just not using containers, it introduces some complexity. Um, not everybody’s familiar with it, you know, EC two is kind of very straightforward. Um, but, but the way that we’re going to, you know, the way we do it, uh, large percentage of the time is to containerize to get, uh, uniformity, to get a consistent product, to get, um, early on indicators of something that’s, that’s not right to automate, you know, vulnerability management, these types of things that are much easier to do.
(17:27):
Um, and just from a scalability perspective, uh,
John Verry (17:31):
Is, is is it that, um, when you containerize your, your, your infrastructure becomes code and it’s easier to look at, like you said, you said, cuz you can workflow automate anything, right? Sure. So, so what you’re saying though is that in that automation process, I’m going to have visibility into the, um, the net configuration of my entire deployment as opposed to getting, uh, uh, serial output associated with, with, you know, with my, with my code, with my third party libraries, then with my actual instances that have been deployed in C two.
Jeff Schlauder (18:17):
Yeah, that’s a, that’s a great way to put it. Um, you know, and, and, and some of the, the, the, the features, you know, when you look at AWS and their, um, their, uh, ecr, um, uh, container registry, uh, capability, you know, I think, I think there’s, and one of the other misconceptions is that containers are more complicated. So I think that it, it’s not necessarily easier than not on the initial setup, but once you have a process in place for how you’re gonna build them, the deployment, the management, the visibility into what’s actually going to be in production and how it’s going to run, um, uh, you know, when you think about things like, you know, um, being able to, uh, roll back to manage, um, uh, you know, um, the scalability of it, it, it’s, it’s actually more difficult to do that when you’re not in a container than when you are.
(19:17):
So I think the upfront of somebody trying to get their head around what choice should I make here to talk with somebody who has an, you know, has their head around it, I guess is probably a good way to put it, to explain it, the benefits of it, but then to operationally see what that really means. Like, let’s go look at ECR and see now that it’s, now that you have your container registered, what capabilities does that give you within AWS that you wouldn’t otherwise have? And I think that’s probably a, you know, how we like to approach it.
John Verry (19:49):
Um, right. And I know that, um, you know, in our work together, you know, um, you rebuild our Oscar environment, uh, weekly, um, and, and that’s done through containers, right? So, and I’m a little bit ignorant of containers. So my assumption is that what you’re doing is you’re deploy, you’re building a new container, you’re testing it, it’s going through your pipeline, and when it’s ready, uh, you’re pushing that into our environment. I’m assuming that our old container stays around long enough that, you know, you’ll keep that there in case we needed to roll back. Um, and what we’ve done is we’ve separated the data from the compute infrastructure and functionality. Is that
Jeff Schlauder (20:27):
Correct? That’s correct. Yep. And, and they can sit in the, in the registry. I mean, so you actually have your version control, you know, you have your, your, your whole history there. Um, so yes, certainly rolling back, but for a lot of other reasons to keep those around. Um,
John Verry (20:43):
So is e is ecr, I’m, I’m not familiar with ECR as a user, Is ECR almost like, uh, a version control, like get for containers, right? I mean, it’s because I guess in a sense, right, a container is nothing but code, right? And, you know, and, and you’re just managing instances of code versions of code, right?
Jeff Schlauder (21:03):
You are, Yeah. I mean that you could, you could look at it that way.
John Verry (21:06):
I mean, I’m sure there’s more to it, but from a simplified perspective,
Jeff Schlauder (21:10):
Yeah, it, it’s, it is, um, that’s a good way to, to be it.
John Verry (21:14):
Um, okay. And one last question, just, and, and curiosity. Would the reason that you would choose Kubernetes instead of ECS B that you want this the containers that you build to be operational, you know, somewhere else? Uh, you know what, like why ECS versus Kubernetes is, is the, you know, I guess the, the fundamental question?
Jeff Schlauder (21:36):
Yeah. Um, there’s whole, you know, people are very passionate about, um, EK eks. Okay. And, and certainly, you know, I think there’s, there’s a few reasons. If, if it really depends on who’s gonna be managing it. There’s no doubt that, um, in my mind anyway, and based on our experience that ECS is, is easier to wrap your head around. Um, it, uh, is easier to, meaning it’s easier to learn, it’s easier to kind of manage. Um, EKS is just a bigger beast, right? It, it, it certainly is. The payoff is there if you have the knowledge and understand Kubernetes and need that level of visibility, portability, um, if you see yourself building, you know, um, uh, you know, your, your clusters in AWS with your containers, and you wanna move your entire cluster out of aws, not that we would want anybody to do that, but if that were to happen, then yeah, you could, you, you could do that with, um, with, uh, eks and you could move that to another, whereas with the e ECS is, is aws, you know, uh, product. So, um, you’re still talking about building, you know, a, a cluster and deploying your containers there, but, um, uh, but being able to take that entire cluster, and I, I really don’t have use cases of where somebody would do it <laugh>, but wanting to move that cluster from ECS over into, you know, GCP would, would, would not be an option for you.
John Verry (23:08):
Um, right, because, because it’s the container contains, uh, AWS specific elements, Correct?
Jeff Schlauder (23:15):
ECS does, Correct. Yeah. But with that comes some, you know, uh, well, not some, quite a bit of simplicity of using and leveraging their services, like tying into IAM and, you know, just other, other things that you don’t have to have a, a, a comprehensive understanding of each individual’s service, um, to feel like you understand ECS itself.
John Verry (23:43):
Gotcha. And then, um, so if somebody was, so let’s say that somebody’s got a, a team and they’re talking about migrating app, and let’s say they’re not working with an outside group like yourself. Um, you know, what, what type of, um, resources should they be looking for? What, what, what experience are there particular, like, you know, if I’m the CEO of an organization and my team is saying, Hey, we’re moving stuff, we’re moving this critical application of ours to Amazon, and I’m a little bit nervous, you know, that, you know, what, what should I be looking for? How would I know if they’ve got the chops to do it?
Jeff Schlauder (24:15):
Well, I mean, there’s all types of AWS as all types of, um, levels of certification that you can, you can get, um, also, you know, AWS certified developers. And so there, there, there’s just a myriad of, um, of, uh, certifications to, that you could rely on to say, this person at least understands and isn’t, you know, it’s not smoke a mirrors. They, they do understand aws, they understand, you know, from a development perspective how to leverage those services. Um, not just how to develop code, but how that development of that code and, and, you know, that process should look, um, as it relates to AWS specifically. So, uh, I, I would, I would say that that is a great place to start is to, you know, look at the individuals currently on your team. Uh, you know, it, it, it takes time. So it’s not a quick, you know, video or ute me that you’re gonna be able to plow through and, and become an AWS certified developer. Um, there, there’s a bit to it, and it’s pretty time intensive
John Verry (25:20):
And well, that, well, the person who, so that, that gives you the awareness of the tools that are available to you and, and, and it helps you in selecting the right, you know, tools within their environment, right? Products within their environment. Yeah. Um, would that be usually the same person that is one of your developers, or do you find that, that, you know, call it cloud architect role as a different role than a traditional, I, I don’t even know the right words these days. Coder, you know, old school coder that’s, you know, sitting in your actual application code?
Jeff Schlauder (25:53):
Definitely different. Um, so I mean the, the, the developer certification and, and what we found there is, I mean, we’ve, we’ve put our own folks through it. So it, it’s important to us, the a when you’re talking about doing architecture and, you know, the folks that are, uh, that, um, have the certifications, um, you know, at that level, that’s a different, a different skill set. Um, but there’s a lot of crossover, um, right? If you’re working with, um, your architect, they’re also, um, likely contributing to the building of, um, of pipelines and mm-hmm. <affirmative>, um, trying to, you know, they’re trying to understand and may have less visibility into what the application actually does, but so when they’re laying out an architecture, they’re gonna have to have some knowledge there of what this thing’s gonna do at the end of the day. Um, and then I think that helps everybody collectively choose the right services.
(26:47):
So they may have, you know, decision points on the, on the, you know, when they’re laying out the architecture, um, that, you know, the, the, um, you know, information around the application itself would be, you know, is a critical input, right? To making the right architectural decision. So like, I I mentioned light sale, right? You won’t find it, you know, an AWS architect who’s gonna likely say the right place to, to build and deploy your app is in light sale. Um, it exists for somebody who’s probably not going to be working with an architect to design it from, you know, beginning to end. Um, so I mean, yes, there are definitely two different certifications, two different people. Um, in my experience, I haven’t found one that does both of those.
John Verry (27:35):
Gotcha. And the, and the people that are, that are coding the app itself, right? Um, mm-hmm. <affirmative> does, does coding, uh, in, is it completely transparent if I’m running this on OnPrem servers versus, you know, is code code no matter where it is? Or is there considerations that when you’re actually coding the application, that knowing it’s in Amazon, uh, you are going to do things a bit differently?
Jeff Schlauder (28:03):
Yeah, there are. Um, there are, I mean, it is, it is not, I mean, like I mentioned in the beginning around how are you gonna handle, um, uh, things like managing secrets and keys and, um, config files, So some of that, um, yes, if you were, if you were doing an on-prem kind of building your own server, installing your own, you know, node and, uh, database and, uh, whatever UI you’re going to to use, having to manage the configuration of, um, you know, the connection strings, these types of things would, would definitely be different. And if you knew you were going to aws, you would, uh, one, it simplifies it, to be honest. And it takes a lot of the, um, the risk out of the, uh, out of the solution because those services have been evaluated, certified, you know, all the way up through different IL levels, impact levels, um, across different compliance frameworks.
(29:05):
So the way that, you know, as an example, s three buckets are configured, you really don’t have to do much there to try to wrap your head around what S three is doing. Um, you know, where you’re gonna se store your secrets is in secret manager. So you don’t, if you’re not using something like AWS and you’re developing, you know, uh, a service AWS secrets manager, and you’re developing an application, that’s certainly a critical, you know, um, uh, input into how are you going to manage this, right? Where are these going to be stored? How are they gonna be retrieved? Where, how often are they gonna be ro rotated? And then how are you gonna manage the application uptime while all that’s occurring?
John Verry (29:46):
Cool. Um, you talked a bit little bit about, um, pipelines and automation. Um, I think we beat that up pretty good. That’s, you know, one layer in there. I guess just to touch on briefly is, you know, the automation is, is how you deploy applications, right? But it’s also how you, how you, uh, validate their security through that, You know, what are the typical things that you guys are leveraging in terms of ensuring the security through the pipeline?
Jeff Schlauder (30:13):
Yeah, it’s a good question. Um, so there’s a lot of opinions. Everybody has their favorite tools, so we’ll start there. Um, you know, I can mention specific tools. We use GitLab, um, you know, for our, uh, uh, you know, for, for our pipelines, for our repository. Um, and we’ve used other tools along the way for us. We use, again, GitLab is just kind of, it does some really, um, great things. Um, but it does have some challenges as well. So I think that when, um, when we start layering on, uh, what it does well and then trying to fill some of the, what we think are, are complimentary services or holes that, you know, where an additional tool would, um, would be beneficial. Um, we, uh, you know, like code reviews as an example, you, it doesn’t matter really what you do within, um, you know, if your developers are developing code, committing that code, um, to the repository, the process from that point of, of getting that commit to what happens to when it goes in production is, is, um, is what we spend a lot of time on, uh, e even down to the developers local workstation and, and ha them having the tools to catch those vulnerabilities to, you know, the typical os Coke quality type of issues locally.
(31:39):
And to even have that scanned locally before their commit, you know, uh, um, is received in the repository. So we, we spend a lot of time on, um, the development process from co-generation through deployment. Um, and while I say, you know, GitLab is our primary, um, you know, solution there, we have other, uh, tools that we use that, you know, in some cases do a more comprehensive, in our opinion, more comprehensive job earlier on in the process. Um, again, down to the actual, you know, developer’s workstation where we can catch things earlier.
John Verry (32:21):
So, so would it be fair to say that if you do a good job in the pipeline, that you can be reasonably well assured that you are not, you’re deploying something which is secure, at least from a known ex? Like we can always be exposed to zero days, but from a, anything beyond a zero day, we can be reasonably sure that we’ve, we we’re deploying an application which is highly secure.
Jeff Schlauder (32:49):
Yes. If you are, if you are using the right services and using pipelines, which, which automate that. Um, so, so as an example, if you are doing your local, you know, um, uh, code validation, um, that’s being committed to the repository on that commit, that is being, that container containers being built, um, so basically an image is being built, That image is, is, is, uh, submitted to, um, the code repo of the E ecr at that point, it automatically gets scanned. So we get a lot of visibility from the time, you know, the, the code is committed to the rest of the process. You know, and again, we’re talking, you know, a minute not, not hours, um, to, to have a reasonable assurance at that point that at least the code and the image itself is passing those, those checks. Now the ECR is not going to scan all of the code. That’s not what it does for code quality. That’s what we use other tools for. But yes, if you’ve made it through that process, um, at least our process, you have a, a very high, in our opinion assurance level that you’re in good shape.
John Verry (34:05):
Gotcha. So we’ve, we, you know, if you think about it, we started at the, how do we get the information that we need to architect a secure application. Now we’ve talked about how do we end up deploying a secure application. So now we’ve got the application out there, um, and I’m very proud of what you’ve helped us do that, uh, whenever I go into AWS security hub, that our security score is 100, usually I saw it dip to 98 because someone hadn’t logged in in 90 days. But, but, uh, we fix that. Um, and that’s funny that somebody, somebody hasn’t used a credential in 90 days. Maybe you should disable the credential. We actually lost points. So, but it, but, you know, so let’s talk a little bit about how do we keep that application secure? How do we ensure that it stays secure, Right? What, how do we monitor that? Uh, talk a little bit about how you’ve helped us, uh, do that. And, you know, cuz I, I think what we’ve done is really good.
Jeff Schlauder (35:02):
Yeah. Uh, I mean, I appreciate that I, when we’re talking about kind of up to this point around, you know, decisions around containerization, then getting into how that code is managed. Um, you know, where it’s, uh, the repository and what happens at, at, um, at, at that stage being picked up from the, or being pushed out or referenced from the repository into ECS or eks, where, where the, where it’s run. Um, I think when we kind of look at that, um, full circle, that’s a point in time. So the, if, if you are doing that and you’re doing that once a month or once every couple months, you know, just by time passing you, you, you know, you start increasing risk. So I think the first piece of that, John, is really the frequency. And for us, you know, we have where, where, you know, an agile shop is most folks are nowadays, but we’re deploying, um, you know, typically once a week.
(36:06):
So we’re going through that entire process now throughout the, the, the, you know, the, the six days in between deployments there, you know, we know that what the fresh image looks like, we know everything will be rebuilt. We feel really good about what’s going out, you know, seven days from now. Um, every step of the way when it’s finally deployed and in, in production using things like config, um, you know, security hub, which, which, you know, provides visibility into, into those types of things. So not the common, you know, is there a code vulnerability, but is S3 set up correctly? Um, are these buckets publicly exposed? Um, you mentioned, you know, hadn’t logged in or is there MFA or access keys that aren’t being rotated? So keeping up with that, um, some of it can be automated, but it just takes, some of it is one and done, but there are just, you know, probably 20% of it that just requires somebody to, to, to pay attention to it.
(37:06):
Um, and it, it, it, unfortunately, some of those things that are typically not automated are the ones that introduce the most risk. Um, so if you set your S3 buckets as an example to, to, to private by default, that’s gonna happen every, every step of the way. But as these users start to, you know, um, either a new user gets added and no MFA is, is, is, you know, enabled at that time or, um, you know, things aren’t rotated or people aren’t using those accounts that can introduce risk. Um, but we, it just, it just takes ongoing management of the overall environment, not just the code and the containers, the infrastructure, but also the, the operational pieces of it,
John Verry (37:49):
Right? And then, and then there’s the other part that, that we do, um, and that it’s great that you can do, is you can set it so that not only are we short, you know, provably secure, but we’re probably compliant. So I think in our environment, what have we able enabled? I think it’s pci, uh, we’ve enabled AWS security essentials and what was the other one we have?
Jeff Schlauder (38:11):
And cisd, it has a ci the
John Verry (38:13):
CIS benchmarks, right? Yeah. Uh, so, um, so that’s a, that’s also a really nice, you know, way of kind of ensuring that you’ve got a high security posture, right? Is, you know, enabling one or more. So a, that helps with, from a security perspective, if you’re choosing good frameworks, but b, that also helps from a compliance perspective, right? Where you can demonstrate to auditors, regulators, uh, key third parties that, that you’re doing things right.
Jeff Schlauder (38:38):
It certainly makes it a lot easier to <laugh>, It makes it a much easier, uh, cleaner, um, narrative when you can actually show the artifacts and, and it’s, um, in the services that you’re, uh, that you’re using, not having to
John Verry (38:53):
Go see. Yeah, I know, I, I, I know that when our customers ask about it, I’m like, uh, you know, here’s, here’s a screenshot from yesterday. You know, and you know, when they see a hundred score in AWS secure, anyone who uses Security hub knows that it’s not easy to maintain a 100.
Jeff Schlauder (39:08):
It’s not. And, and you know, for some folks, a hundred’s not the right answer. You know, AWS is, is in it to, you know, um, they’re not a nonprofit, let’s put it that way. So <laugh> some
John Verry (39:19):
Of the,
Jeff Schlauder (39:21):
Some of the default rules that will be there. Like you should replicate all of your, um, you know, three puppets to another availability zone or region. You know, there’s some of the things just inherently are gonna have cost to them, um, and may, but that’s an availability type of, um, you know, uh, concern or risk. So if that’s not something that you’re, you know, overly concerned about, um, you know, those are, you know, more business, there are some business decisions to be made around is the right thing to do to get to a hundred percent, or are some of these rules just not appropriate for our business? They should be disabled with the business justification of why. And, um, and go from there. So
John Verry (40:03):
Yeah, same thing with the Microsoft Security Center. If you, if you’re in like, you know, we’re an E five shop. Yeah. You go into Microsoft security sometimes and you look at the, and you’re like, Yeah, I don’t think we really need to worry about doing that particular thing. Oh yeah, by the way, that would cost us, you know, X dollars per month per employee to enable for no real reason.
Jeff Schlauder (40:22):
Yeah, it would be a nice feature if in there they had a, an estimating, you know, bill next month’s, bill next to each other,
John Verry (40:29):
<laugh>, that would make it, that would just make it too obvious what they were trying to do though, Jeff. I mean, they can’t, you can’t, you know, that’s like, that would be like, you know, a consulting firm coming in and saying, uh, hey, we found this really significant issue and or here’s how much we’ll charge to actually fix that issue. I mean, it just makes it just a little bit too much of a, uh, uh, too, too much tie there, so to speak.
Jeff Schlauder (40:51):
Yeah.
John Verry (40:53):
Uh, so we beat this up pretty good. Uh, anything we miss? Last thoughts?
Jeff Schlauder (40:59):
Um, no, I mean, I, I think, yeah, probably last thought is, is around the, um, we talked about development practices, but really through all of this, if you know what I mentioned, we put a lot of time into the, you know, from code development to, um, to deployment. But that’s, you know, and it, it kind of sounds old school, but the, the segregation of duties there, right? That peer review, that development team, we have found to be kind of the, the most critical piece. So having those peer reviews, um, cuz again, it doesn’t matter how great the, the, the vulnerability management tools are, um, the, the value of having a second set of eyes, not just on is this a vulnerability, but is it the right thing to be doing? Right? Is it the right approach? Um, is it scalable? Does it kind of go outside of the parameters of, um, of our paved road and the direction we want to go?
(41:58):
Um, ease of use, right? As I mentioned, each time you bring in something custom, you bring in, you know, in our opinion, uh, you know, risks, support issues, these tech, potential tech debt down the road. So other than, you know, tooling and automating and managing vulnerabilities, sometimes the vulnerability is just, you know, the person themselves and, and not, not maliciously, just inadvertently. Um, so if you have, you know, that additional ability and not everybody does, where you can put that gate in and have somebody, you know, truly look at how something was done, not if it’s secure or not. I think that is, to us, that’s a big part of it.
John Verry (42:40):
So you’re talking like a, a, an old, literal, old school code walkthrough.
Jeff Schlauder (42:45):
Yeah, I am.
John Verry (42:47):
So that’s really interesting to me that you say that. So if I, if I took a SAS tool, right? And I run it against code, you know, from a security perspective, I think that would catch the vast majority of things. Maybe what it would miss would be logic errors or something of that nature. So like, I’m just wondering, like when you think about the value of code walkthrough, cause I think a lot of people bypass that. I don’t think there’s as much code walkthrough going on as, you know, since we’ve got these automated tools as there used to be back in the old days when I was in application development. So the question becomes is, um, am I, how often will I catch a security error versus how mu how often am I catching these other errors, types of errors that you, or not errors, but uh, non-optimal coding, uh, techniques or non-optimal technology leveraging, you know, what percentage will I find in one versus another? Will I find true security vulnerabilities through code walkthroughs that the tools will miss?
Jeff Schlauder (43:50):
Not typically. Okay. Not typically, to be honest. You, you, you just typically won’t. I mean, the tools do a really good job not just on the security piece, but, but even just how things are, if you’re declaring a, a variable, you know, and, and then you’re not using that, it’ll even flag that our tools will mm-hmm. <affirmative> and just say, Hey, this isn’t necessarily a vulnerability at this point, but it’s just not being used. It’s sloppy, right? Mm-hmm.
John Verry (44:14):
<affirmative>, so yeah. You’re not reallocating this memory over here, right? It, that’s not gonna be a bug, but your code’s gonna run better if you
Jeff Schlauder (44:20):
Did. Yeah. And it’s just, or something wasn’t closed correctly or, um, you know, uh, so these types of things that may not be security issues, um, but it, it’s more of the approach, did you solve this problem? Is this code that we just developed that pass all of our, um, code quality checks, good code, the answer’s yes. Right? We’ve d we’ve determined that through our process, we feel really good that the code is, is good, but is it the right approach to have solved the issue? And that’s the piece that that can sometimes be, um, overlooked without a peer review to say, I get how we did this. We, but, but what we did was we did it in the UI and we, um, solved the problem in the, in the UI instead of the api. So what we would like to do in our, you know, approach of simplicity and ultimately security is do as much on the API side as we can if we’re gonna get there. Either way, it’s not gonna be flagged either way, but it just could have been done differently. Um,
John Verry (45:23):
And, and technically that could be technically doing any type of, you know, validation, you know, in the browser is not a good idea and could be a theoretically a security issue.
Jeff Schlauder (45:33):
Yeah. It can just be things where, you know, if you think about the basics of an application, where are the, where are the items coming from in the select box that you’re using? Are those, you know, stored in the ui? Are they being pulled from a database being retrieved from an API call? So either way you can do it, there’s no, you’re not gonna get a vulnerability by building a, a, you know, a list of eight select box items in a, in the ui, but it’s not supportable, right? It’s mm-hmm. <affirmative> it’s not the right,
John Verry (46:02):
But you, you, you, you could theoretical, like, I guess the only thing is, is that if somebody, you know, if somebody manipulated that using a tool like burb right? Some type of proxy, if you, if you’re not capturing, if you don’t have some type of input validation in the api, in theory, something could go wrong, correct?
Jeff Schlauder (46:18):
Yeah. I mean, and it, it cascades from there. So I think just bringing that back as we, we haven’t given up on, on doing peer reviews, we think No, I
John Verry (46:28):
Think it’s, I think it’s great that, I think it’s great that you do, and, and I think, like you said, writing more elegant code, writing, more efficient code, writing code, which is better aligned with the business objectives. Yeah. Right. You know, that’s what you’re gonna, you know, I could see you clearly could get through a code walkthrough that the tools would have no way of doing, right?
Jeff Schlauder (46:46):
Yep. And I, you know, where we use, you know, JavaScript framework, so there’s all kinds of things that you can do within that, that, you know, other frameworks like a, a a go or you know, are, are a lot more rigid and aren’t going to let you make some of the, you know, have as much flexibility or maybe make some choice as you wouldn’t otherwise have the option to make.
John Verry (47:06):
Gotcha. Yeah. Um, so hopefully you prepared for this question. You know, your eyes are probably scanning the document now. What questions he about to ask me? I’m gonna, I’m gonna give you the question. Uh, gimme a fictional character, a real world person you think would make an amazing or a horrible cso and why?
Jeff Schlauder (47:24):
Fictional character. I
John Verry (47:26):
Didn’t. Oh, he didn’t prepare folks. I didn’t, he did not prepare.
Jeff Schlauder (47:29):
I didn’t prepare for this one.
John Verry (47:30):
Jeff, you were doing so well. You were doing so well up to this point.
Jeff Schlauder (47:33):
This is gonna be, um,
John Verry (47:36):
This will haunt you as you gonna sleep tonight. Well,
Jeff Schlauder (47:38):
Let me flip it back. How about you? Gimme one first year. Let’s turn this around.
John Verry (47:42):
Well, no, listen, I’m sorry. I’m sorry. Who name is on the show? I’m the start, right? You’re at best today. You’re a guest star, coast guard, so of that nature.
Jeff Schlauder (47:53):
So being put on the spot, not even being able to name a fictional
John Verry (47:56):
Character being put on the spot. I sent you this agenda earlier in the week.
Jeff Schlauder (48:00):
You gimme the character. Don’t,
John Verry (48:02):
Don’t say I put you on the spot, <laugh>,
Jeff Schlauder (48:04):
You gimme the character. I’ll tell you why they’re good or bad.
John Verry (48:07):
Um, uh, let’s, he gave a character, uh, Niles Frazier.
Jeff Schlauder (48:14):
Niles Frazier.
John Verry (48:16):
Did TV show Fraser?
Jeff Schlauder (48:17):
Yeah. I shouldn’t have given you that.
John Verry (48:19):
You, you, you, I gave you a character. Ah, to I, uh, how about gimme a tv? Gimme a tv show. A movie that you love that I might know.
Jeff Schlauder (48:27):
Um, Walking Dead.
John Verry (48:31):
Never watched it.
Jeff Schlauder (48:32):
Oh, um,
John Verry (48:34):
<laugh> won’t order. No, don’t watch
Jeff Schlauder (48:39):
It. Oh my goodness.
John Verry (48:40):
How about community? Ever watched community? No. No, man, we, we, you and I don’t have the same TV days. Breaking, breaking bed.
Jeff Schlauder (48:47):
No, don’t watch it.
John Verry (48:49):
West Wing.
Jeff Schlauder (48:51):
No, it’s not at my alley. Wow.
John Verry (48:53):
Sopranos, Sopranos,
Jeff Schlauder (48:55):
Sopranos. Yep. Let’s do it.
John Verry (48:56):
All right. There you go. Uh, poly walnuts.
Jeff Schlauder (49:00):
Oh my goodness. These are, so, I should have prepared for this question. I would’ve thought my answer all lined up. I think, I think, and this is gonna mess up your whole segment here, <laugh>,
John Verry (49:13):
What
Jeff Schlauder (49:13):
Makes, I think the root of the question is what makes a good CISO or
John Verry (49:17):
No, no, no. The root of the question is we, like, we wanna be entertaining. Uh, you know? Yeah. And I think me busting your chops worked. So I think we’re gonna let, I think purposefully we’re gonna let you off there. I I think that this is the entertaining part of the show, and me roasting you is pretty entertaining, at least to me. Uh, hopefully the audience was gonna
Jeff Schlauder (49:32):
Pull out Elon Musk there at the end, but I’m not, I’m just leaving it go
John Verry (49:35):
Now. I, I, you know, Eli, Too late. Too late. That’s fair. Um, all right. Uh, so if somebody wanted to get in touch with you, what would be the best way to do that?
Jeff Schlauder (49:46):
Um, probably email, Uh, actually, my, my mobile phone’s probably the best way to get in touch with me. I get a lot of
John Verry (49:54):
Email. Sure. You sure? You sure? You sure. You’re sure you wanna put your mobile phone number on the internet?
Jeff Schlauder (49:58):
You know, it’s, it’s a catch 22 because of How
John Verry (50:00):
About how,
Jeff Schlauder (50:02):
Let’s do, let’s do email.
John Verry (50:04):
LinkedIn. All right. LinkedIn.
Jeff Schlauder (50:07):
No.
John Verry (50:07):
All. So it, so what, what would be the email address?
Jeff Schlauder (50:11):
It’s j Slaughter, s c h l a u d e [email protected].
John Verry (50:20):
Cool. Uh, despite your horrible performance on my last question, this was pretty damn good. So I wanted to say thank you.
Jeff Schlauder (50:27):
You’re welcome. Thank you.
