Nov 10, 2023

Unleash the power of DevSecOps and Cloud-Native Security with Kayra Otaner

Host: Hi everyone, this is Purushottam, and thanks for tuning into ScaletoZero podcast. Today's episode is with Kayra O'Tanner. He has over 20 years of experience in PCI SOX-compliant work in both New York and Wall Street. Currently, he is a director of DevSecOps at Roche. Previously, he has worked at ADP, WPP and FICO.

He's a trusted DevOps and SecOps advisor. He frequently speaks at international DevOps and SecOps events since 2016. Recently, he presented at RSA on implementing Zero Trust with a dedicated DevSecOps pipeline.

Prior to that, he has also presented at KubeCon, Detroit, DevSecOps, Washington, DC, Moscow, Lithuania, and Turkey. He has a unique perspective.

and he has launched DebsaCorp teams at ADP and also at Rosh. Thank you so much for coming to the podcast, Kera. For our audience, do you want to briefly share about your journey?

Kayra Otaner: Yeah, thank you for having me on this on this podcast My journey has become you know I have been in Linux and open source ecosystem for over I guess closer 25 years now started as a as a developer and then quickly switched to systems admin side and then it emerges of all the Compliance on PCI which was launched in 2005 and it sucks compliance. I guess around 2008 or 7 after the Iran thing

I moved to security space and as with everything in IT, we change shapes, we coin new terms, but we also improve the process along the way. So I see that very agile way of doing security. I've seen the manual, very mundane, paper work-driven way of doing stuff to evolve into the DevSecOps way. And I started working on this space, I would say for the last next six, seven years.

And the DevSecOps has been the blood of everything that we do but there was not enough automation and tooling place. Now with the old tools out there, like chat GPTs and infrastructure as a code, most things that we've imagined before us are now currently available to us.

Host: Right. So and you have a very you have a lot of experience on this field and I'm interested to learn from your experience. Right. Before we start, I generally ask this question to all of our guests and I get different like answers, unique answers as well. So I'm curious, what does a day in your life look like today?

Kayra Otaner: So it's a very, I'm in a unique and different position than most other people in. I work for a company in Europe and I'm in East Coast in New York area. And my day starts very early than most other folks are. And I have a lot of meetings with the European teams and also the West Coast team. So my day is very, very different than regular DevSecOps people's way of doing things. We do...

We are in the process of building a world-class team for this large organization. Ultimately, we are mentoring, coaching a lot of product teams within the organization to show them the best or better way of doing stuff. So providing governance, guidance, coaching, mentoring, is, I guess, that's one thing that every DevSecOps architect has to do. And my day evolves around that thing primarily.

Host: Okay, that makes a lot of sense. So for today's episode, we'll talk about a few topics, but let's start with DevSecOps. So as you have been in the industry for some time, you have seen many trends, right? Earlier, we did not even have DevOps. Now, then we got into DevOps patterns. And then security was never part of that. So then which led to the DevSecOps move. And

The concept behind it is all about like finding and addressing security issues as soon as possible in the development cycle. With that being said,

What's your take on the transition? Like how is the transition going on right now?

Kayra Otaner: I guess you mentioned one important thing, the detection, detecting the issues as early as possible. I mean, as you know, the shift left is almost like a synonymous with the DevSecOps. When you see DevSecOps blogs, they always mention shift left. And that almost always means that you have to do early detection. But what we are seeing, the evolution is continuing with everything else, that the expanding detection was getting us into the next phase of doing stuff, meaning prevention and remediation. So I'm seeing huge step towards the auto remediation capabilities, huge step towards our prevention capabilities that wasn't part of the DevSecOps Circles.

And as a skill to practitioner who has been in this space for 15 years, we keep constantly firefighting, meaning detecting things not able to prevent them, not able to remediate those.

Say, take the log4j as an example. I have the sticker on my desk that I've been showing to a lot of people in my calls, because that's the unique case that everyone knows about. Guess what? You know that you have like 10,000 instances of log4j all around in your infrastructure.

What's gonna happen?
How are you going to remediate those issues?
Is it manual?
Is it automated?
How can you be smart about those type of incidents that happens?

I guess the evolution towards auto remediation. And what we call them is prevention technologies or preventative controls in the compliance space are getting more and more importance. You know, DevSecOps was evolved from the DevOps, but it was coining two terms, DevOps plus SecOps. They were like two separate disciplines or two separate approaches.

Now we are saying with the prevention things, DevSecOps really becoming real DevSecOps sector ops, ops to dev with all this complete loop. I guess that's very exciting times for any profession, security profession to be involved with any DevSecOps initiative.

Host: Make sense. So now the follow up question to that is when let us say an organization did not have depth psych ops practices in place, they want to get into depth psych ops.

What kind of challenges they might face and how can they address them?

Kayra Otaner: Alright, so there are two approaches that typically we see in the industry. And also there is no one size fits all approach. If you're a small organization, you try to upscale your dev people. I mean, if you think about a pyramid, you have like 10 developers.

For 10 developers, you have like 5 ops members. And for 5 ops members, you have one security personnel. So it only makes sense to upscale the dev to do more security to get them more involved in implementing security or codifying security into their infrastructure or into their way of things, doing things. So it is essentially what we call security escrow. But this is an approach that is very common and I call this an anti-paradigm because it results in a hybrid situation that you are not needed DevOps or DevSecOps.

What I'm trying to do in large organizations, which is much easier to implement if you have a lot more resources than small startups have, we do upscale security people to do more development, meaning asking security practitioners, which is top of the pyramid in terms of the number of individuals that you have in your team, to get involved with more automation of things in the dev side, meaning getting pre-commit hooks, pre-push hooks implemented, getting security scaling implemented on behalf of the dev teams and not ask them to integrate those security checks into CICD, but have a dedicated team to operate the security checks on a separate pipeline, which is the time of my talk when I present in RSA conference like six months ago in April, 2023, employing zero trust pipeline, zero trust dev sec of pipeline for the large organizations. So these two approaches are valid depending on the size of organization, especially after seeing any big organizations like the ones that are that was mentioned.

It is the small startup approach really works for large organizations. I can easily say that.

Host: Yeah, and that makes sense. And one of the things that you highlighted was like pre-commit hooks or having a separate pipeline for your security findings. Right. That, that matches with like something we heard from Matt, who was in our earlier episode, he was also talking about that.

You should not just block the rollout of a critical feature just because there is a security issue, but maybe work with the team so that you can do a fast follow up and get those resolved sooner than getting like sitting the item sitting in the backlog for longer duration.

Another thing that I liked about is you mentioned about shift left, right? And a lot of organizations are facing challenges on that front because you have to incorporate security at the earliest stages. So

How can organizations find that balance that they shift left incorporate security earlier, but at the same time doesn't affect the speed of the deliverables?

Kayra Otaner: All right, so a very good question. I mean, it's very common that when we say, when we talk about security, that immediately in people's minds becomes a thing that is going to slow them down, right? It is always a speed bump. It's always like a speed bump that you can't go faster than this.

The reason for that is, you know, the security people are conscious of all the risks that is out there and we can see the first hand, all the risks that are being executed by the attackers or adversaries against infrastructure that we are trying to defend or protect. Developers are not on their side.

They can't see the first time, they can't witness that effect first hand. So the breaking builds with CI-CD pipelines or toll gating is very common thing that kind of slows down the adoption of dev seconds because you are practically asking developers to own something that is going to slow them down or prevent them from moving faster, hence the shift left in large organizations that you want to have a dedicated team that does it for them without asking them to own their piece.

And also what we see, what we try to say is we don't want the security people, especially the DevSecOps people to be not be called team of no, we want them to be called team of how. We want to show how easy it is to implement this and also supplement their decisions before they get staff deployed to production, but not block them.

And it sounds easier to do this without tollgate, but there are bunkers that we typically design. There are tier 1, tier 2, tier 3 applications or product teams. For tier 1 teams, we want to do tollgating because they are already in good shape because of the trade model that we have done, because of so many other things that they have demonstrated to us. We don't want to tollgate them. We want to give them the rating between 1 and 10. Oh, you guys, your build that you just finished building, part of your CI looks 7 out of 10. So we don't want to do anything.

There are teams that are high risk because of the business criticality, because of the sensitive data that they're handling, because of the monetary volume that they're managing. We want them to be targeted or prevent, have all the eyes on them, having four eyes on everything that they have. That has to be targeted. So it's not a blank thing that executes that case applied across all space. And so there is this third bucket, which is very common. So once you have like a somewhat meaningful metrics defined in your organization to measure the quality of the coding or application development, anyone below the average should be automatically targeted. Anyone below the median should be automatically targeted. It's not a blank statement. So that can be applied in varying degrees or different ways.

But the security measures of the team plays a critical role and there are a lot of good ways to measure that. Like how many developers you have, how many vulnerabilities you have, what is your vulnerability per developer ratio? Are you beyond the average accepted thing for the organization or you love that average? So the targeting, if it's a blank thing, you are going to end up having a lot of headwind and friction, which is not something that no one likes. On this side, you don't like the other side and developers typically they don't like it neither. But coming up with common sense, In planning commons and security policies that are aware of the risks is the way to go.

Host: Yeah, I loved how you started right like generally security teams are seen as roadblocks right? It's like the way you highlighted that the security team should not be looked at as a team of no but other teams of how can they enable you to become more secure. So that sort of takes the conversation towards like culture right because most of the organizations have some sort of culture and.

If you have DevSecOps mindset, then you know that, yeah, security is important. You will start doing it from earlier in the pipeline rather than later as part of the STLC process.

So any tips that you have for organizations to ensure that they have the culture, right culture in place so that they incorporate security earlier rather than like when they get hacked or something like that, they work on the security issues.

Kayra Otaner: You know what, this can turn into a very open and frank and sincere group therapy session very easily because that's our stress point. There is a saying, I remember hearing this a while ago and I heard it like a couple of months ago again, culture eats strategy and transformation for lunch or for breakfast. So if you're in a culture that is already well established in this organization, small or large organization, an all-or-only one.

The culture is going to eat all the strategy, all the best practices that you bring from all other places, all the high level influencer influence that you might try to bring into your organization. That's going to be erased as a breakfast or lunch. So the culture is important.

It is, unfortunately, it takes a while. I mean, in cultural transformation or any DevSecOps adoption for small or large organization, going slow is smooth. When you go smooth, you're going to be able to do it Smooth is fast. So it's contradictory. You wanna go slow. You wanna start having a lot of open, frank, sincere, transparent organization events within the organization. And start having some sort of influence sphere created around the things that you can control. That expand your influence sphere towards the areas that you can't typically enforce anything. So that's a slow process. It's a human psyche, human nature that we kind of reject the things that are new, right? In human life most examples.

Security is the one that is easier to reject because it's always going to slow you down, strictly speaking. But explaining the risks, making sure everyone is part of the same team, the same ship, and also explaining that if you don't do this, we will fall behind on our bonuses, we will fall behind on our KPIs. That is going to affect global everything. And also seeing a lot of bad news that's...

I don't want to give any specific examples, but there are like every day, even yesterday was a big bad news on, you know, how companies lost their MFA tokens and whatnot, to get leak credentials. It's always happening. Very easy. Wall hanging fruit type of stuff are killing us. It is very easy. You just have to be conscious about the things that is controllable very easily. It's like, you know, learning how to drive. You have to learn while your parents are sitting right next to you when you're 16 and 18, you have to be driving with them for a while and then gradually become a driver license, get a driver license. So that's the intention. You move slow and repetition is the key.

Host: Make sense. So there are two aspects right on the culture as you highlighted one is let's say as an organization you have a culture you're following it how can security teams work more closely with the DevOps team a dev team or operations team So whether it's like having a security champion or whether having brown bag lunches-

What have you seen that has worked to build a relationship between security and let's say product or engineering side?

Kayra Otaner: I mean, it is one part, one team approach. It's not multiple teams. There might be some organizational boundaries. There might be some organizational boundaries that involves the HR hierarchy. Like you report to X, the other team reports to Y. The CISO and CTO, all organization structure.

But if you essentially have to focus on you becoming the part of the same team, or acting as if you're in the same team that makes things easier. That starts with having daily meetings or weekly meetings or on a regular cadence meetings in any cadence is very critical. And also having very open show and tells, brown bag sessions, lightning talks, sometimes like quarterly or monthly is very effective that we have seen.

The transformation and showing things to be done, we call them dojos, Showing tells in the way that you execute those steps and showing that oh, it's very easy because I never know learn that It's that easy showing them is easy as easy as I can I'm some of copying pasting some snippets and you're putting them into pipelines or some other places He's going to make the transformation a lot easier and smooth So it's not you're always sending him an email like you're saying that this has to be done or can you do this when you? Let me know this is not going to work in corporate America especially startups. It's not going to work because People have a lot of reasons to get busy with some other stuff that is not security-related.

Host: I love the idea of like lightning talks and the dojo site doing it together versus just training and just training your team rather like doing like hands-on workshops where you can show that how easily they can make improvements and then incorporate those.

Kayra Otaner: I mean, nothing is rocket science anymore. I mean, I don't want to underestimate the importance of the things that we do, but once you start working on this stuff, it's not that complicated. And I just want to refer us back to the thing that I said, we don't want to be the team of no, we want to be the team of how. How do you demonstrate that you have the know-how, you have the how skills?

That's why you have to organize these dojo type events that are critical and recurring, and a cadence that everyone knows that you have a nice, cool, thing to show that is going to make everyone, this one team, you know, benefit from. So you know, that's once they realize that it's not conflicting, we are building a collaboration and we are consolidating a lot of efforts together.

Building coalitions is what we call is very, very important. You know, the most easy way of doing things is having Brownberg sessions.

Host: Yeah, that makes sense. So I want to talk slightly about the cloud now. I'm pretty sure you, like Roche, must be working with major cloud providers. And when it comes to the cloud, there is a shared responsibility model. Sometimes we assume that cloud providers take care of security for things which, ideally, we should also take care of. We should take care of it.

So how do you see organizations who have recently moved or are moving to cloud think about security in a cloud native environment?

Kayra Otaner: I mean, in general, I'm not talking about anything specific to the employees that I'm currently associated with. In general, you know, shift, lift and shift approach is what we define the migration towards the cloud infrastructure, right? That really works. And here's why. The benefit of having stuff running in the cloud is not just copying, pasting stuff in the way that is executed.

You want to get the benefit from the proper compartmentalization of things, proper containment of things really the only meaningful way of putting stuff into cloud is to get benefit from the containers and the consolidation things that the infrastructure that they're providing.

You might be aware of this, most viewers of this podcast, we're going to also be aware of it. There are four Cs of cloud native security. You want to follow that four Cs, there are four layers in cloud security journey, cloud native security journey that has to be protected individually.

That is cloud infrastructure, cluster infrastructure, container itself, and the code. So if you pivot that four level thing towards the left, you're just gonna see stuff from left, the code is on the left, container is right after the code infrastructure, cluster, all the IMs and RBX, et cetera.

They all have to be carefully designed because so many of those mechanics that are in that cloud native infrastructure cannot be mapped to the old pet VM world of doing stuff. That you might be using virtualized infrastructure or like on-prem infrastructure with so many things that are deeply buried under your OS level that has to be decoupled completely from it and then let them manage by the control plane or CRDs inside the clearance cluster.

So it's a whole new journey. And I see that shift and lift type of operations are typically opening up Pandora's box because the vulnerabilities that you might have on your pet ecosystem or on-prem ecosystem are visible, not unmanageable very quickly in the cloud infrastructure.

Host: Yeah, yeah, makes a lot of sense. So a follow-up question to that is, and you touched upon this earlier as well, around automation, especially when there is a digital transformation happening, an organization is moving to cloud, they either do not spend a lot of time setting up the automation, and again, not just for deploying the workloads, but also from a security perspective.

What like according to you,

What role does automation play when it comes to security in cloud native environment? Like does DevSecOps work?

Kayra Otaner: Yes, I presented a couple of days ago in an internal event, and I call this DevSecOps is codifying security. If you look at from a very high level, DevOps is codifying your infrastructure, right? All the Ansible, Poplar, Teraform, Jaml files, or even Jenkins pipelines is codifying one way or another your infrastructure. If you announce codifying your security tooling into your infrastructure, that's not DevSecOps.

So codifying infrastructure and codifying ops infrastructure and codifying security has to go hand in hand in order to have full-blown dev secops, you know, infinity tool. So automation is key and automation was not possible to a certain degree until like five years ago. I mean, now we can talk about policies written in policy as a code language like Rigo or Checo or some other languages.

All that like we are not, you know, if you just built into the current control plane. So all these things that wasn't possible before, but the biggest problem that I'm seeing that's happening right now is we are asking developers to write the policy S code or security S code for their own stuff. That's a maker checker problem. You can't ask people to check if they are compliant with the policy.

That policy S code and security S code to a certain degree has to be written by another entity with different organization boundaries applied to them because of the human nature, the maker-checker problem. So when we try to do dev-seccups in a small scale startup environment, we ask a lot of that stuff, Policy as Code, Red Go, hey, you own it, you build it, you integrate with CICD.

That's not how it works, unfortunately. Security has to be part of every day, day-to-day activities, but the ownership and execution of those has to be different that segregation of duties, we call that, that in sox compliance or make a checker problem in everyday life. So that automation has to be owned by dedicated security folks.

We call them their circumspect in large organizations, has to be able to write the code and automation for security guest code implementation and policy guest code implementation to the level that it's checking the code that is living in synergy and harmony with the CI CD operation that is already owned and executed by the dev slash devops teams.

Host: Mm-hmm. Makes sense. I want to follow up with one of the things that you highlighted earlier. It's like when it comes to cloud, you have to look at the four Cs, code, container, cluster, cloud. And as part of the shift left, a lot of focus is being paid to containers. Sorry, to the code world. And when it comes to code, nowadays, there is a lot of adoption of open source software.

I think there was a study, recent study, which showed that about 82% of the code written by enterprises out of that 82% of the code is open source, like using some external library. And that sort of makes you vulnerable to supply chain security, like the attacks that happened to let's say SolarWinds or Twilio or PyPy.

So from a security perspective, how do you look at this? Like code being one of the key aspects, using open source software, making you vulnerable to, let's say, supply chain security. How do you look at it?

Kayra Otaner: So when you look at the raw number of CVs, raw number of issues and their CVSS attached scoring, it's very easy to get very depressed very quickly. The number of CVs on average in 2020 is around 77. There are 77 CVs disclosed every freaking day.

So ultimately what happens is it's not sustainable, it's not manageable. So we cannot fight against that volume of the velocity of CVs coming towards us with every operation that you might put in place, it's not easy.

And the reason why it's not easy is that, you know, we assume that every CV is exploitable. Every CV is exploitable under special circumstances. So the rating of those CVS, CVEs is being shifted towards what we call EPSS, Exploitative Prediction Scoring System, driven data that is machine learning driven using the KEV, which is, you know, non-explorative, vulnerable to this, that just passed thousand announced CVEs yesterday or two days ago, or last week, actually.

So these data, once it comes together, it kind of gives us proper tooling to do the prioritization. So the CVE fighting or vulnerability fighting becomes much more meaningful and executable. So the automation that we are putting in place is focusing on that properly prioritized CVEs to make the development devsec of scale without the proper prioritizations in place, software supply chain issues with the open, whether it's open source or proprietary, coming from big OS vendors like Microsoft, Red Hat or other ones, you know, it is not manageable. You have to take into the EPSS like actionable data into consideration, otherwise, software supply chain, especially the ones that are out there, that has been out there for like long period of time is not easy.

And also one thing that I should mention, you know, We kind of briefly touched on that a couple of minutes ago. The reason why we are moving to cloud is not, I should say the reason why we are moving to cloud native security is to get benefit from the containerization. So if you have properly contain applications, that is ephemeral and immutable, the containers, bodies, not like that, then you minimize the risk. The risk is still there, you minimize the risk with common sense policies. The biggest gain that I see in that forsee is the containerization space.

Having the containers properly hardened, we use cloud built packs, we use distro-less images or very properly hardened images, that is minimizing the risk that we ultimately have to inherit from the open source community. Because we cannot go back and fix log4j on December 4th, that was the day that was disclosed, the patch was available, but there was multiple attempts to fix it really.

So you cannot really, really rely on that proper containerized environment, proper hard and foreseen cloud native operation. The open source software supply chain issues are losing its emphasis or importance because in terms of the risk or governance and risk and compliance perspective.

Host: I feel that we should have a separate episode altogether on the four C's of cloud and how you can secure those areas. But I'm loving it, like especially when you highlighted about like the distro less hardened images using those for your containers or like doing instead of using CVSS score, maybe focus on EPSS because that shows whether those are exploitable or not.

If it is not exploitable, even though it is critical should not be the highest priority, right? Because developers cannot work on 100 critical and high in a sprint. They have to focus on few because they also have to deliver some business requirements. So that brings me to the next question, which is around the landscape, right? How has this landscape changed?

So you have been in the industry for a while. You have seen the DevOps practices, DevSecOps now, now cloud native security using DevSecOps in cloud native security. How has the landscape changed?

Kayra Otaner: I mean, assume that hypothetically speaking, you are in an environment that you manage to detect all the issues, all the issues that is deeply buried in your products, infrastructure, home, my art. So what's next? Instead of assuming that you have a thousand vulnerabilities or a thousand issues that you need to fix, now you realize the complete picture has 10,000 weaknesses and vulnerabilities. What's next? What are you going to do?

That's the landscape is that's the landscape, you know, the direction that I see that a lot of vendors are moving towards today is detection is already kind of, you know, 90% reliably executable with the right tool, right mindset, right approach. The auto remediation is the space that is everything is going to get bigger. Right now, roughly speaking, roughly less than 10% of the things can be auto remediated. I'm going to give you a couple of vendor names.

There's OpenRewrite initiative, Moderna is one vendor that I know that's really doing good stuff on their front. There are a couple other vendors that are doing recipes to answer to those common issues that is widely seen in either Java language or like Python or some other languages or frameworks. So the auto remediation is going to be from less than 5% today, going to be like 20-30%, hopefully in three years.

Auto remediation needs we're going to end up having. And then what's next? Auto remediation and whatnot. What's next after auto remediation? Five years from now, we're going to start talking about prevention because we're going to detect very quickly and auto-remediate quickly, but that's not proper way of doing things. The humans are doing things better and better, so we're going to start focusing on practice and focusing on prevention. That's when the cloud native build backs and proper containerization and some other stuff comes in place.

So I recommend that any DevSecOps practitioners, that's what I do for all these global organizations. Three tracks, major three tracks. Expand your detection capabilities to the fullest. That's not easy to get to 100%, but you can get to 97%. Start auto-remission programs that is starting at very minimum like three to five percent of things that can be automated, but it's going to slowly go up. And start your third track, which is prevention.

Without these three pillars DevSecOps is not DevSecOps. It's just a name. It's a nice coin term that gives a lot of good emotions, a lot of good feelings to a lot of good people, but it's not applicable. So you have to have those three pillars almost simultaneously executed so you lift the scale of your organization. You lift the security measures of your infrastructure or your organization to the better places.

Host: I totally agree on like every at every time there is a marketing hyped word, right? Like today it's Gen.ai earlier it was blockchain. So similarly, even in security, at one point we were talking about detection, like show me what vulnerabilities are there. Now we have slowly moved to remediation. So I love how you mapped it to a landscape, right? How the security landscape is evolving.

Any emerging trends or technologies that you are noticing which folks, our listeners, or our audience should be careful about or should be interested to learn about?

Kayra Otaner: I mean, you know, chat GPT or GPTs in general, GPT-3. I've been following GPT-3, GPT space for since GPT-3.0, which was this three, four years ago. 3.5, 4.0, all these things are getting things done very easily and this place, you know, GPT technology or AI plays into the auto remediation space, but not typically in the prevention space. The auto remediation and detection can be, can benefit from all this stuff.

The prevention is always strategical thinking and knowing what's going to come next. So I recommend experimenting with all the nice tools out there, but not relying on them 100%, but 80% of the time they are reliable and start implementing them as early as possible. As a matter of fact, a lot of large organizations are doing pilots with Co-Pilot and Co-Pilot X or some other tools out there.

Host: Yeah, makes sense. And you are spot on the like using LLMs and all of that to enable your engineering or dev teams to remediate issues that increase their productivity overall as well. So makes a lot of sense. And that's a great way to end the security questions for this episode.

Summary

Thanks Kayra for the insightful conversation. Here are a few important points which stood out for me:

Organizational alignment is the most important factor for Security roadmap. Pro tip - when speaking with Business, Security Teams should use the Business Language instead of Technical Language.
Build a One team culture. Brown Bags, Lightning Talks, Dojos, etc are great ways to collaborate with Engineering and Product teams to build relationships, show value and impact of Security function to other parts of the organization.
When it comes to Cloud Migration, Lyft and Shift does not work. Follow Cloud Best practices from a packaging and containerization perspective. And, focus on 4 Cs - Code, Container, Cluster and Cloud from a security perspective.

We also have a section which highlights on rating security practices.

The way it works is I'll share a practice and you need to rate from one to five, one being the worst, five being the best. And you can add context also why you rated it as one or two or three or five or something like that. So let me start with the first one. DevOps practices are needed to move fast and to deploy code to production. Security is not my most, like highest priority right now. So I will do it in the next time.

Kayra Otaner: You want me to break this rate, you know, statements? It's not less, it's not more than two. And there might be some reasons, you know, why this statement might be valid, but you know, DevSecOps is the way that we define a software safer, sooner. So DevOps is software sooner, DevSecOps is software safer sooner. Quicker and safer approach. So this statement can, should only get like between one and five, two.

very close to being worse.

Host: Okay, all right. The next practice that I want to talk about is Continuous integration is a must for DevSecOps practices. Security architecture review is performed on a regular basis.

Kayra Otaner:I agree. I mean, continuous integration is not a security practitioner by design. It's a DevOps practitioner. Continuous integration should not include security in a large organization in a proper way. It should be part of another pipeline.

That's the way to go in zero trust message model in advanced level implementation. Ultimately, you want the people to focus on things depending on their unique needs. So a small organization might implement that in the same CI phase, but the road store, the Nirvana point, should be always having that decoupled and people should be aware of that. And I say that statement, having the security in CI is like three between one and five, not more than. I'm very conservative.

Host: Yeah, OK, that's fair. The last one that I want to talk about is use of strong passwords that contain mix of uppercase, lowercase, letters, numbers, symbols, and changing them frequently toward reuse of same passwords.

Kayra Otaner: I mean, the way that we design passwords are for humans. Secrets are for machines or services, right? So if you're talking about passwords for humans, it should always be accompanied by MFA and even like some other advanced passwordless approaches. MFA is a must have. And most people like me, I have been in this space for like 20 years that I have to manage various passwords for various things.

I use password managers. I use password managers that generates like 40 character long, upper case, lower case, digits, symbols, et cetera. That is not easy to guess. It's not easy to build for us. But ultimately, my password manager is protected by a lot of things, including MFA. So the importance of having long passwords from the security developer perspective, yes, we should anticipate and enforce.

I will say minimum 16 digit, 16 character long, alphanumeric password so that we ask people to use password managers with MFA. Without MFA, password manager is not a good idea.

Host: Makes sense because you have one sort of like database, which is not secure, right? You just have a password to access your database. Then once you have access to the database, then you can go to any service and. You have access to the king.

Kayra Otaner: Certain things, I have a user in database, assume that I'm a developer, that I have a user, then I have a password for that database, and my password is kept in my password manager somewhere that I have to go through MFK. So I can add additional layer to that on top if I put it properly implemented.

Host: Right, right, right. Makes a lot of sense. And that's a great way to end the episode as well. Thank you so much, Kara, for joining. It was lovely to speak with you on multiple topics. Yeah. Thank you. And to our audience, thank you so much for watching. Hope you have learned something new. If you have any questions around security, Share those at scaletozero.com and we'll get those answered by an expert in the security space. See you in the next episode. Thank you.

Kayra Otaner: Thank you. It was a very nice conference. Nice to be here.