A Cloud-First Approach With Johnathan Keith

[00:00:25] Announcer: Hi, you're listening to The Secure Developer. It's part of the DevSecCon community. Join us, June 23, for DevSecCon 24. It's a free global vendor-neutral, community-driven conference that connects developers, security and operations teams to learn and enable the integration of security into their development practices. Find out more at devseccon.com.

This podcast is sponsored by Snyk. Snyk is a dev-first security company helping companies fix vulnerabilities in their open source components and containers without slowing down development. To learn more, visit snyk.io, s-n-y-k.io.

On today's episode, Guy Podjarny, founder of Snyk, talks with Johnathan Keith. Johnathan is the Director of Information Security for ViacomCBS Digital. With over 20 years of experience in information security, cyber security, cloud security and cloud architecture, he has worked as a subject matter expert in the inform security domains across several industries, such as banking and finance, visual government, and media and entertainment. His area of expertise are in container security, infrastructure as code, application security and network security.

Johnathan has a Masters of Science in Information Systems with an emphasis in cyber security, as well as several industry-leading certificates. He's currently managing an infosec team of several security architects and security engineers with initiatives to advance container security and zero-trust throughout the entire ViacomCBS Digital organization. We hope you enjoyed their conversation. And don't forget to leave us a review on iTunes if you enjoyed today's episode.

[INTERVIEW]

[00:02:14] Guy Podjarny: Hello, everyone. Thanks for tuning back in. Today, we're going to go into the world of media and enterprise and securing at scale within un-empowered fashion. And to dig into all of those, we have with us Johnathan Keith, who is the Director of Information Security/CISO of ViacomCBS Streaming. Johnathan, thanks for coming on to the show.

[00:02:35] Johnathan Keith: Thanks for having me.

[00:02:36] Guy Podjarny: Johnathan, before we dig in, can you tell us a little bit about what is it you do as a Director of InfoSec? And also just a bit about how you got into security and into this part?

[00:02:45] Johnathan Keith: Sure, absolutely. So as a Director of Information Security for ViacomCBS Streaming, I'm responsible for overseeing several brands, 10 plus brands within our ecosystem, from our sports digital, to our Paramount Plus platforms, we're basically responsible for delivering content to our direct-to-consumer and developing our direct-to-consumer applications. So in our world, we have a plethora of security engineers and security architects that work directly with the site reliability engineers and also the web developers or making security as a process that's baked into development. So we're very hands-on. We're very involved in the development of the applications. We’re very involved in the development of configuration management within the cloud and building out cloud security. We’re a seamless process for the business partners.

And, for me, what my journey and security started roughly 15 years ago, I started off in the financial services. Sort of predate what is now considered to be FinTech. For me, I started off with somewhat of a business background in business and marketing, but then IT security was also a passion of mine. So we're talking in 2007, 2008 roughly when there was a lot of changes going on in the economy, there was a lot of changes going on in the real estate market. And we saw more and more financial services really had a need for security across their IT platforms. And I just saw an opportunity to quickly get into the industry and just pretty much hone my skills and develop the passion that I had, which eventually led into the cybersecurity world, which also led into what is now basically a primary focus on cloud security. So that journey took me through a lot, working for a FinTech, working through some government agencies, also working for some smaller FinTech organizations, and now into the media and entertainment segments. So it's come full circle to where I really saw myself being 15 years ago. I see myself now in my role, which is pretty much the ideal role for me with the combination of having a strong cyber security, cloud security in business aptitude.

[00:05:01] Guy Podjarny: Yeah, got it. Well, it's a rich journey. I'm curious, like how did you get sort of the first step into security kind of moving from the business side to tech land and security land?

[00:05:15] Johnathan Keith: It was actually an accident, to be honest. I was working for – I live in the Atlanta Metropolitan area, and I was working for a bank, and they had an internal incident within one of our marketing departments. And at the time, there was a security team, but it was a fairly small security team. And they didn't have a whole lot of knowledge on the application that was compromised. Well, I had more knowledge around the application that we were using. But then they had a little bit more of the security protocols. But I quickly caught on to what the security protocols were. And we quickly realized what the vulnerabilities were and what the flaws and security flaws were within the application itself. And they were like, “You should come work for us.” So I'm like, “Sure. How much are you paying?” So it just became a natural transition.

[00:06:04] Guy Podjarny: Got it? Well, it's a great opportunity, seizing moment there to dive and open up what became a pretty awesome career.

[00:06:11] Johnathan Keith: Absolutely.

[00:06:13] Guy Podjarny: Before we dig into security and development and all the sort of the great initiatives you mentioned, can tell us a little bit about just the organizational structure for it? Like you're running the security team, what does the security team look like? And how does it relate to sort of the product, the development teams?

[00:06:28] Johnathan Keith: Sure. So my security team is made up of roughly 12 individuals, so half are senior level engineers. And the other half are senior level architects. From my team standpoint of view, we handle various security domains around application security, around secure SDLC. We also help build out configuration management for the development teams throughout the different business partners. So our different business partners expand through, like I said, our sports digital world, are Paramount Plus world. And within their world, basically, they have direct access and direct responsibility to the development of the applications. But yet they work through us to make sure that, like I said earlier, that they're baking in security standards into the application development.

I take more of a proactive approach as opposed to a reactive approach. I know a lot of security professionals are into doing the web application scanning and gathering the vulnerabilities and the findings and things of that nature. And a lot of times, to me, that leads to be more reactive as opposed to proactive. What I like to do is make sure from development, to QA, into production, we're actually finding vulnerabilities, whether it's the vulnerabilities within the code, whether it's vulnerability within images. We're heavily looking into our Kubernetes security and our Kubernetes clusters. Making sure things are private when they should be private, public when they should be public from a networking standpoint of view, looking at container network interfaces. So we're across the board looking at all aspects of the infrastructure that supports the application that will eventually deliver the content to our consumers.

[00:08:09] Guy Podjarny: Yeah. And when you say we in this context, is it the security team that's looking at these kind of vulnerabilities or the sort of the security assessments at different phases? Is it the teams that run them? Like how does sort of the interaction, or I don't know if it’s divisional responsibility –

[00:08:25] Johnathan Keith: It is a security team, but we're in direct communication with the developers. We're in direct communication with DevOps and the DevOps leadership as we're reviewing these reports and we're reviewing these findings, because we believe in knowledge is power. We believe in keeping them educated on the findings and not just passing down a directive, because there are situations where we may not have direct access to the cloud environment. We may not have direct access to the actual EC2 instance or the cluster itself. So therefore, albeit we discover the finding, we're not the ones who necessarily have the access to remediate. So we do have to work and communicate with the DevOps and the different developers through the brands, and therefore being able to make sure that we apply some sort of fix or some sort of remediation based on the findings that we have discovered.

[00:09:14] Guy Podjarny: Got it.

[00:09:14] Johnathan Keith: So it's definitely a shared responsibility.

[00:09:16] Guy Podjarny: Yeah. Understood. So you're – I guess maybe deep diving into this, and we'll talk DevSecOps in a sec here. So as your security team – If we talk about the practicalities of it, right? As your security team runs those scans, what does it look like? Do the scans run in like the build process? They ship data out? Which is I'm trying to think about scaling, kind of learnings and tips and tricks and all around how does your, well, I imagine is sort of an outnumbered security team kind of collaborate with larger engineering folks?

[00:09:47] Johnathan Keith: Sure. So I mean, we have a plethora of tools and services. So we have a set of tools that are directly involved in the build phase. For example, we can tie in a lot of our container security platforms into their CI/CD pipelines. We can also have them installed daemon sets on the hosts that are actually running their containers. We can also use scanner CLIs. Basically a CLI format with scanners for them to be able to directly run those type of scans directly on their images within their repositories, whether you're using the gcr.io, or ecr.io, or GitHub. We can use those CLIs to be able to run those scans and return those findings.

We also have tools that we use to scan the entire infrastructure, where basically we can look at configuration and configuration management by scanning the infrastructure and returning anything that's failed as far as inside that is not considered to be best practice. So we'll have certain paths that we run through those tools. So we'll use like CIS benchmarks, or we'll use some CSA benchmarks, things of that nature, to be able to discover those findings. And once we get all that into a report or into a user interface, from there, we either share that information, that report, directly with the business partners, or they actually have access to the user interface so they can be able to discover some of those findings in real-time. And there are situations where within the CI/CD pipeline, they can actually apply remediation in real-time. So we can actually turn on auto remediation if necessary. So therefore, there's not really any human interaction in some of those cases. It's just a process that we have in place. And both the DevOps and the security personnel are educated and involved in that process.

[00:11:31] Guy Podjarny: And how do you decide between these two? I guess it's not two approaches, right? But between when does a security person need to sort of review the results or assess them and sort of drive them, versus when does your team maybe like own the tool or sort of put the tool in place to sort of get the security insight, which is expecting the development team to act on the result?

[00:11:56] Johnathan Keith: It depends on the business partner. And it depends on the knowledge of the developers within that business partner. Some business partners have more autonomy than others, because they actually have someone within their DevOps that has some sort of security responsibility within that business. Others do not. So it's not really a cookie cutter approach to me. We know our business partners. We know their business. And we know where we have to be more involved from start to finish in the information security process. So we do have some business partners that do have their own, say, for example, security expert who just so happens to be a DevOps person. And in those cases, they will have full autonomy and access to our services and tools where they can apply some of those remediations. In some cases, they can even run those scans themselves, whereas others don't have that luxury. They may be a smaller business. And they may just have subject matter experts around SRE or just around web development and they know absolutely nothing about information security or cloud security. For those, we offer more support, more service.

[00:12:57] Guy Podjarny: Got it. Yeah. That makes sense. Kind of adapt the surrounding. You're building it. I'm sure, tools and techniques have evolved. What's the top tip of a practice or a technique that you've grown more fond of over the last year or so?

[00:13:12] Johnathan Keith: Make sure you keep your people trained. I can't say that enough. Whether it's your security personnel, or whether you're working directly with DevOps and you're training them on how to use the tools and services. Provide them with training and workshops, and make sure they clearly understand the functionality and the features of the tools. If not, you're pretty much asking for trouble if you don't, because if you just hand someone the keys to a kingdom and without giving them training, then you're going to have a lot of false positives. You're going to miss misconfigurations. And it's really going to defeat the purpose of having that shared responsibility, because you haven't provided them with the proper knowledge and the proper training.

[00:13:51] Guy Podjarny: Yeah. That sounds like a lesson learned, a hard learned lesson. So this would be training. You're not talking about sort of secure coding education. You're talking about training as making the most out of the tooling that you have in place to ensure that they are, I guess, testing for the things that you're aiming to test for?

[00:14:10] Johnathan Keith: Yeah, that would be slightly separate. I mean, that would be different than doing something like secure coding, training or doing training on secure SDLC. This is actually training and workshops around using certain tools and services that we have available to the business partners so that we're not just passing on a service to them or passing on a tool and giving them access to it without giving them the knowledge that they need to understand the features and the functionality within the tool.

[00:14:36] Guy Podjarny: Got it. Understood. So I guess along that vein, what are – I guess, if you think about the top practices, if you come to a new business partner, hopefully none of them are really at the kind of point blank, but still you're kind of working with a team that is a bit more nascent. What's your sort of typical priority list of what do you put in place first?

[00:14:58] Johnathan Keith: For me, I like to take a look at what is there process around their cloud security. Currently within, if they're a multi cloud environment, taking a look at their configuration management within the cloud. Next, I like to take a look at the application security. I like to have a clear understanding of the application architecture. What are the primary languages that they're using? And basically, who are the individuals supporting those applications? And then after that, the third thing for me is probably more into trying to figure out more about the risk management, around the organization. How does the organization currently manage risk? How does your organization currently determine what really is their risk? Because certain business practices can tolerate more risk than other. Certain business practices are in a position to accept risk more than others. Some have a higher risk appetite. So I like to kind of go in that particular order depending upon the setup of the organization. But I think the three go hand in hand and they kind of chronologically stack in that particular order, because you first have to get an understanding of the environment. Secondly, you have to get an understanding of the applications that are basically driving the business and generating revenue. And then you need to clearly understand what is the risk that's being introduced from doing the previous two.

[00:16:19] Guy Podjarny: Got it. Okay. Yeah, it makes sense. So you're saying, if I could just correctly echo back, you're looking at some core practices for someone to understand just like a methodology around security. And then after you go through that, cloud and application, and those are kind of my trigger words [inaudible 00:16:35]. I’ll come back to those, to that distinction in a sec. But once you assess those, then you come back to say, “Okay, now, are we smart about knowing where we're focusing for it?” Is that kind of a correct view?

[00:16:47] Johnathan Keith: Correct. I think those three for me are what I would call the core competencies. I think those are the competencies across not only information security and cybersecurity, just the organization in general. Because if I go to an organization that has a cloud-first approach and they have really no idea what their best practices are or what their guardrails are in general within the deployment of their resources and services, then you're already behind the process. And that's not just a security thing. That's just in general just best practices around cloud strategy and also cloud migrations.

[00:17:20] Guy Podjarny: So let's get back a little bit into that cloud and application security. So I find, and I know I'm fully biased, those lines are getting blurry a little bit, right? You kind of come into it. A lot of cloud is sort of managed as applications. How do you – When you think about cloud security versus application security, how do you draw the line? What do you put in what bucket?

[00:17:39] Johnathan Keith: I think, for me, with application security for our business and the media and entertainment world, sometimes we're at a slight disadvantage, because we have to think about our customer. And our customers are the general public. It could be anyone that could be a customer. So we have to think about delivering content as securely as possible, but at the same time, making sure we're providing what our customer is paying for, because they're paying for a service. So there are some times where we have to have some compensated controls. We may not be able to be as secure or as locked-out as I would like to be in my world. But at the same time, we want to make sure at least we're mitigating any threats or any risk around that direct consumer, content delivery, that basically drives our businesses or drives our revenue as a reason why everyone in the organization has a job.

Whereas from a cloud security standard point of view, I think that's where we can make up the difference, because our customer doesn't have a clue what runs in the background. Our customer doesn't have a clue of the infrastructure. They don't know the difference between whether we're running an application on the GKE cluster or if it's running on a series of auto scaling EC2 instances. So therefore, we can make sure that we add a little extra layer of security there that we're looking at layer three, layer four, and layer seven risk and vulnerabilities and making sure that we're adding the necessary security controls. So at the end of the day, our applications that reside in those environments and rely on those resources can do what the application is intended to do, and that’s deliver the content to the customers. So I think that's where the balance is. And that was one of my first challenges when I came to this organization, because I knew I'm thinking content delivery. I'm thinking customer, and I'm thinking revenue. So at the end of the day, I can't hinder the drive of the revenue, but I still got to make sure I'm protecting the customer, also the organization.

[00:19:36] Guy Podjarny: Yeah, interesting. So there's the customer orientation. And then there's kind of the infrastructure versus sort of code maybe aspects of it. So I guess within that mix, for instance, when you think about container security or you think about infrastructure as code security, how do you bucket them? Like do they fall under the infrastructure bucket and kind of the platform and sort of keeping the customer protected? Or are they more apt?

[00:19:59] Johnathan Keith: They’re more apt. They're more apt. So we tie our code security and our security SDLC under our application division. If I had to give you a breakdown of my team, so we have specialists that are more focused around app sec. We have specialists that are more focused around cloud security. And then we also have specialists from the threat intel and threat modeling background. So when it comes to code and code security – And you also got to wrap repositories security into that now, because that's where the code resides, and that's where we're seeing some of the biggest risk where repos are accidentally opened up to the public or people are actually embedding secrets in their code. So we wrap that all into our app security. So that helps us from development QA into the actual production phase when that application becomes open to the public.

[00:20:49] Guy Podjarny: Yeah. Make sense. So we've been in the industry for a bunch of years now. If not, your first rodeo. And DevSecOps is a bit newer than that. And you got into Viacom. There are probably some established practices on it. So I imagine it wasn't – There some change required to sort of embrace DevSecOps. So maybe let's dig into that. Maybe for starters, like how do you – When you're asked what it means to sort of do DevSecOps, what does that start? And then maybe we dig into a little bit about how do you see embarking on the change to kind of get into that mode?

[00:21:22] Johnathan Keith: I’m just going to be honest. When I joined, initially, this organization. So we started off actually as CBS Interactive. And then as we went through the merger of the company, we went through some reorgs and some name changes, which brought us to where we are today, ViacomCBS Streaming. But when I joined this organization three years ago, there was no DevSecOps. It was basically security versus DevOps. I mean, that was just the reality of the situation, which you see that quite frequently across a lot of organizations. I mean, from a developer standpoint of view, security was often looked upon as a roadblock that, here, they have this code, and they need to push out to this application, because their manager is basically telling them they have to add this new feature to the application. But before they do that, guess what? They got to check with the infosec person. And for a long time, they felt like that was a roadblock and delay in their process.

So, for me, one of my first responsibilities and one of my first initiatives was to build rapport, to build relationships, to show the developers and the DevOps that we're in this as a team. It's not infosec versus DevOps, because at the end of the day, we're supporting a platform that supports our customer base that provides them with a service and generates revenue. And also why I let them know that we speak their language. I mean, I came from a background of being an architect. I came from a background of being an engineer. I was familiar with programming and programming languages, which made it a whole lot easier to build those relationships and build that rapport. And then as we started building out some of the current tools and services that we provided and we provide to those business partners, we got their buy-in. We had their input. We didn't just go out and just POC a bunch of tools that have the title security, or Sam or something in the name. We made sure that it was a tool and services that was going to be beneficial and would add value to those developers and to those brands and to those application owners and some of the stakeholders in many cases, so they understood the reasoning behind why we were doing what we were doing on the security team. It wasn't intended for us to be a roadblock. It was really intended for us to not only provide them with more security posture, help them reduce risk, but also optimize the way they did their development and also improve performance of the overall application, which actually happened, because we focused a whole lot in the beginning just on misconfigurations.

And just by solving the issue of misconfiguration, a lot of the DevOps teams, they not only optimized their process, but they actually saw improvements across the various applications. And it was a no-brainer. And then they realized that, “Hey, this is a different approach. This is not traditional information security. This is more DevSecOps, SecDevOps, where we're actually working together and developing a partnership. And everyone has a vested interest to make sure that we're delivering the content securely.

[00:24:26] Guy Podjarny: Yeah. I love the quality facets. If you build it right, if you detect misconfigurations, if you identify security concerns, you'll help improve other aspects of the system. So this sort of drives this empathy, this sort of close collaboration, working together versus with them. What was the hardest part about applying this transformation?

[00:24:47] Johnathan Keith: I think the hardest part was getting some of the application owners and some of the leads to open up more on their development process, because they own that. And when they develop their applications, they have a system in place that's probably been in place for years, because they understand their business. They understand their customers, and they understand what is intended for them to deliver. Well, for us, the first thing we wanted to do as a part of potentially looking at misconfiguration is also looking at the application architecture. Maybe there's a way we can re-architect something where seamlessly you're actually remediating a problem that has existed for the last two years. So getting them to open up and show us that architect, to show us that inside world of theirs, was probably the biggest challenge, because there was sort of the misconception that if we open up that architecture, to information security, they're just going to tear it apart, or they're just going to force us to re architect and make changes to something that we've actually worked two or three years to build. And that wasn't the case. It was basically infosec coming in providing a second set of eyes from a different perspective with a group of trained security engineers and security architects that understood the development phase, that understood operations, and here's the recommendation. And that was probably the biggest bridge that we have to cross. And once that level of comfort was there, it made things a whole lot easier for us to now collaborate and work together and have a little bit more synergy across the application owners, and then information security, architects and engineers.

[00:26:29] Guy Podjarny: Yeah, yeah. No. I love that. Really, it’s about establishing trust in there. And how did you achieve that? So like you come along, you have those. What are some techniques? I'm sort of thinking, if a listener is in this sort of typical stage, what are some techniques to break through to earn that trust?

[00:26:48] Johnathan Keith: Just jump in the fire. We came in during the time of this process where we had one of the biggest special events of the year going on, and that was the Super Bowl. That was when we were actually hosting, streaming the Super Bowl in 2019, which we started preparing for it a year before that in 2018. So that was the first test of whether this process was going to work or not. I mean, it took an – I would say at least an entire year of working together through various projects, building out different phases of the platforms that we're going to support the Super Bowl, because that was actually the first year that we were actually streaming it live as well too, to really, really open up that trust. Because it's like, “If this doesn't work, there's no return, there's no going back.” So it either has to work for we're going to have a problem. We're going to have to tear all this down and rebuild relationships all over again. So that was the first initial test. We just jumped in the fire headfirst. We came up with a lot of strategies. Spent a lot of time on Zoom meetings, basically going over working sessions, architectural calls, and just spending that time together and actually having working sessions. And actually, literally problem solving in some of these conference calls was really what helped bridge the gap and build that trust in that report. We would have different testing phases where, I say, we did some workload testing, and we'd make a recommendation to re-architect something within the application. The application owner would go back to their team. They'd run that in their test environments. It would be successful. We'd come back the next call and they'd be like, “Wow! We didn't realize it was going to be that easy.” I was like, “Yeah,” all we had to do is just try it and test. And if it's successful, great. If not, we go back to the drawing board.

[00:28:38] Guy Podjarny: Got it. You have to jump in.

[00:28:40] Johnathan Keith: You have to jump in.

[00:28:40] Guy Podjarny: This is a great kind of an improvement of the relationship between sort of the DevOps and security any they work together. Another player in this world is the auditors. And sometimes, sort of being more empowering or trusting of other teams might be a little bit harder to digest kind of on that front. What was your experience there around practice – Has there been a change in your approach to sort of how do you work through audits and insurances when you embrace DevSecOps?

[00:29:11] Johnathan Keith: That is still a challenge for us, because we actually have a separate group that manages that aspect of our security. So we don't really do direct, say, for example, PCSI, DSS audits, or our own internal compliance audits. It’s actually handled by a different team that's more on our corporate side. And I think, for us, we realized that was a big challenge for the application owner, because instead of putting him in a position where they had to deal with two different groups, we tried to filter a lot of that process for them, because it could create confusion, it could create ambiguity around, “Okay, I have this one infosec team that is a little bit more technical and a little bit more hands-on, but then I have these auditors that are telling me I need to do this this way. I need to do this that way.”

So what we tried to do to take some of the workload off the application owners in the DevOps team is we tried to be that liaison. So we would work directly with the auditors and we'd work directly with the court side of the information security team and make sure that we were passing on the necessary requirements to the application owner. So we would kind of just funnel everything through one line of communication.

Because, once again, going back to it, we're in the process of still trying to build relationships ourselves. So we don't want to confuse anyone while we're trying to build out those relationships. So we just try to follow it. We try to streamline the process, simplified and make sure if audits were required, we provided the requirements through some of the architectural reviews or through some of the DevSecOps discussions that we were having with the application owners. So they would not have to directly communicate with the auditors unless it was necessary, unless it was something more like PCI-related where they had no choice but to go through some sort of PCI DSS testing.

[00:31:04] Guy Podjarny: Yeah. Well, definitely kind of keep the eye on the target as you build the relationships. You want to avoid distractions.

[00:31:11] Johnathan Keith: As much as possible. And we get – I mean, once again, we were at the process of, for the first time, streaming a major sporting event. We had never done this before. There were so many pieces to the puzzle. There were so many people involved. The procedures were changing almost on a daily basis. It was a real juggling act. But it was something that I felt like it was a great test, that when we passed the test, it's simplified the process of building relationships and collaborating in the future.

[00:31:41] Guy Podjarny: Yeah. Yeah. So now you've established something. You’ve kind of gone through hardship.

[00:31:46] Johnathan Keith: Exactly.

[00:31:46] Guy Podjarny: So this has been – There's all sorts of questions and paths we can continue going down. We're kind of getting up to time. I’d love to – Before I let you go here, one question that I ask every guest coming on. If you think about someone sitting in your chair sort of in this role five years from now, what do you think would be most different about them? And it can be sort of CBS specific, but maybe even just industry wide? What do you think would be most different about their reality?

[00:32:15] Johnathan Keith: I think for anyone coming into the role, say, five years from now to be a CISO or a head of information security or cloud security, I recommend that person maintain their technical prowess as much as possible. I think a lot of times that with CISOs and other execs, you start getting to a certain level. You feel like you have to move away from the technology side. And I think, to me, that is a mistake, because the technology is ultimately what's driving our business. It’s ultimately how we deliver our content and applications to the industry.

For example, API security is something that if you try to really have that type of discussion with most execs, they're so far removed from that aspect of it. They're not knowledgeable enough to figure out how do we approach that. Microservices is going to be a huge impact to our industry. And especially in content and media and entertainment, you need to fully understand the process of microservices. How it works? And where we're going to start seeing more risks introduced to our environment with micro-services. So if I'm talking to a future CISO, my advice to them is stay into the know as much as possible. Study the technology. Understand the technology. Of course, you still will have your management duties. You still will have your executive duties, but take the time, 25% a week, just to make sure you're studying, you're reading up on technology, you're understanding new services, new products. If there's different languages being used across your organization. Understand why the developers and understand why the DevOps and the SREs are using what they're using, the purpose behind it, the business reasoning, and that will help you kind of project and forecast a program, a cloud security program, an infosec program that is not only going to provide security, but it's going to provide business value because it supports the existing people, processes and technology.

[00:34:28] Guy Podjarny: So Johnathan, thanks. This has been great. Thanks a lot for coming on to the show.

[00:34:32] Johnathan Keith: Yeah, thank you. Thank you. It's my pleasure.

[00:34:34] Guy Podjarny: And thanks, everybody, for tuning in. And I hope you join us for the next one.

[OUTRO]

[00:34:42] Announcer: Thanks for listening to The Secure Developer. That's all we have time for today. To find additional episodes and full transcriptions, visit thesecuredeveloper.com. If you'd like to be a guest on the show, or get involved in the community, find us on Twitter at @devseccon. Don't forget to leave us a review on iTunes if you enjoyed today's episode. Bye for now.

[END]