Panel – Move Fast and Don’t Break Things

Hello, my name is Caroline Wong. I am so pleased to be joined by my good friends and colleagues swathi Joshi and Kim Jones here today at Cloud native day. 2022.

We are here to do a panel and our panel is called move fast and don't break things. We as security people thought that there would be no better title for a talk for cloud native day. So in all two common belief is that you must move fast.

And then you must sacrifice Security in order to achieve that speed. I think that's a dangerous assumption. Which is based on a misguided belief that cyber criminals are entirely focused on large juicy targets.

I think the caseya ransomware attack and numerous attacks are attacks over the past few years have actually proven to us that it doesn't really matter. How big or small your organization is. Any organization can be a victim of a Cyber attack regardless of size regardless of maturity.

So our conversation is intended to debunk a myth. That security and speed do not mix. Scaling companies often prize Innovation Above All Else and some even bolt-on security as an afterthought in a world where many of us work remotely this can add further pressure to building a comprehensive security strategy.

But how are we as technology practitioners to build in proactive preventative measures? When we are strapped for money talent and guidance. Today we're going to talk about why we think security testing is critical.

And will touch on an idea that automation alone may not be good enough. We will be sharing practical tips with you on which practices we have seen work in modern software development life cycles, and we'll also talk about what does security at scale mean So I will now ask my colleagues to introduce themselves Kim. Why don't we start with you?

Let me down that last sip of coffee. I apologize. Hey, everyone absolutely great to be here.

My name is Kim Jones. I am currently the director of security operations at into it the you may know not know into it. But you may know what's product such as TurboTax.

QuickBooks Mint Credit Karma and MailChimp. I am in the midst of my 36th year in security. So I'm officially the old security guy sitting on this call.

I spent 11 of those years as a chief security officer Chief information security officer in various Industries building and Management Programs while I have not run development shops, most of the programs that I have built operated and mayonnaise are in companies that have very strong development arms. So implementing security into a development lifecycle as a security practitioner is not something that's new to me. So I'm really happy to have this conversation and be invited to have this have this talk.

Has like Caroline I believe that this is one of the biggest myths in our go faster environment regarding development may have some differences of opinion as to what's causing it, but we're going to get into that I think later on so absolutely happy to be here. Awesome. Thank you so much Kim for joining us and for bringing your 36 years of experience.

I'm myself consider Kim Jones to be an elder in our community when I have super tough problems that I'm trying to solve I often go to Kim and ask for advice. Thank you so much for being here with us today honor and a privilege my friend. Swathi, how about you?

Tell us about yourself? Kim Caroline, thanks for having me. Hey everyone who's watching and swathi Joshi and the BP of SAS information security at article and responsible for five six different security functions a red team our offensive engineering team ethical hacking team well-management detection engineering incident response governance risk and compliance.

Prior to Oracle. I let the detection response team at Netflix and before that. I was with Mandy and helping customers through advanced persistent attacks.

And so, you know last kind of six years of my career a focused on more cyber defense operations and on the defensive side of things and prior to that I was at I was at after Associate's Gartner and there was more focused on application security identity access management some more sort of proactive security kind of things. I'm excited to kind of put both of those together here are article and Lead both the reactive side of the house and the proactive side of the house and excited to be Chad and about, you know, scale and testing challenges to Kim's point, you know, I started as a developer and then I've been in you know environments and Mandy and it was more customer focus right as a consultant you see various different environments at Netflix. It was more internally Focus.

But still in support of consumers and here at Oracle, it's it's all kinds of clients. Right like from Healthcare to energy to financial vertical to you know, as as our assassin businesses, so large and wide and some excited to kind of share some of the lessons learned and some of the tactics that we've had success with on the team. Amazing.

Thank you so much. I have to take a brief moment and just do a plug for the humans of infosec podcast of which swathi and Kim have each been guests and so quick aside. If you want to know more about these amazing humans, not only what they think about security testing but a little bit more about their lives and their careers be sure to check out their episodes on humans of infosec very briefly.

I'm Caroline. I've been working on this field for 17 years starting off as a practitioner at eBay and at Zynga did a little bit of product management at semantics some management consulting with digital and I've been at Cobalt for the last six years. So, let's Dive Right In Folks and I'll ask swathi to go first.

If you don't mind. What do you think about the following statement? To move fast you must sacrifice security.

Yeah, I definitely think getting in the last five six years. The Security Programs have proven that that's not the case. Right and I do think like we should it that phrase of you know to move fast.

We should sacrifice security and I think we should look at that. Look at the intent of the phrase a little bit and not as much you know, what does it literally mean? If we look at sort of the recent programs and the way the Security Programs have evolved saying the last you know, the last 10 years and this is for sure not true.

Really. I think one one catch here that I do want to mention that sometimes I think we fall into this trap of if everyone is doing security then no one's doing security right like if we say, hey we have to really, you know move fast. That's why we're gonna have a super Student, you know approach to security.

And in moderation both centralized and distributed approaches will work. Well if we kind of fit together, but if we take the extreme approach of like it's completely distributed then it's the classic case of say in a meeting can someone take this action item? Right and then no one takes action item versus asking specific people to take ownership.

And so I do think that we need a team that's focused on security full time. But of course, we need partnership with you know, other other business functions, especially engineering functions to kind of move that forward. I also think that the negative of the security programs and security organizations has shifted right now.

We see we see everyone talk about security is a business enabler. So I think a security teams we have understood that we realized it as a community that that's the that's the best way forward. We have to enable the business we can slow slow them down.

But at the same time we have to have some checks like our security should be able to do our job. So I think I really like, you know, Jason Chan who I work with at Netflix. He let the Netflix Team there when I was part of it.

He has this really nice phrase where he talks about guardrails and not Gates. So I think that's a great analogy to say here. We're not trying to put gates in but we have to have some type of God rails to operate in A fantastic, you know, I'm so glad that you shared this about Jason and about the Netflix security function.

I from my perspective the Netflix security team has a clear reputation for in fact really doing security at speed swathi before I passed to Kim for his thoughts on the statement, which on repeat when we get there. I wonder if you could actually also provide us with an example. What is the difference between a guardrail and a gate I expect that most folks are listening very closely and and I would love to hear a little bit more about this.

Yeah, I think one simple one comes to mind is you know, the classic security awareness or the developer. Advocacy training grade. Do we want that to be like a checkbox for compliance?

Everybody Must do security or rather? Why don't we look at sort of you know, high high risk population or say critical population that have admin access that deal with financials and say hey folks like we want to do a bit more targeted training for you all to see how you know, how can we educate our folks to be better at this? So how can we use our you know historical incident data and also look at specific user groups with Emily elevated privileges to kind of do more targeted training, but say more blanket you have to do this type of type of approach.

Yeah fantastic. I mean to me that sounds like actual risk management. That sounds so realistic.

Thank you for sharing that with us Kim on to you. Tell us what do you think about this statement to move fast? You must sacrifice security.

Well, one of the I I guess advantages of being politely the older Statesman in the room more directly. The old security guy in the room is I have the luxury of maybe being a more pointed the about certain things and I'm going to be a little more pointed about certain things. It is an absolutely self-serving fallacy.

On both the part of the developer and both the part of the security team. It is a self-serving fallacy that I believe that both sides of the equation and the organization that has be both of these groups in them has perpetuated over the years in the decades. It's interesting swathi to hear you say we've changed our tune about security being a business neighbor.

I remember when I interviewed for my first ciso job in 2003 and said I believe security is a value add the business late neighborhood. So I I would respectfully disagree that this is a change in tune because we've been saying it for more than two decades. It's more matter of how we Implement that enablement in environments that don't fit into the traditional regimented non Innovative environments that many of us had to grow up and or did grow up.

Regarding the fallacy itself. I think the fallacy exists for a couple of reasons on the one hand. We have business needs and people redevelopers in this case who are being rated compensated and rewarded for Speed and efficacy to the market.

How quickly can I push the code how quickly can I push the effective code? How quickly can I get from point A to pointing at V out the door? Obviously, I'm speaking the broad generalities, but I think I'm being reasonably accurate here.

On the other end. I have a security professional whose job is yes. I need you to go faster because you're the guy or gal who makes sure my paycheck doesn't bounce but in doing so you're creating potential vulnerability for our customers, which creates high and immediate risk, you're creating a central risk for us within my application stack in my application environment.

So, how do I reconcile making sure you're doing what you need to keep the spice flowing? Sorry, I'm sci-fi fan and I watch a lot of movies while I figure out how to do what I do and do so in a balanced risk management approach and invariably many many moons ago and dinosaurs roamed the Earth and there was this thing called waterfall. Yeah, you remember those?

Yeah. Yeah Google it. I know you're little young.

It's out there this thing called waterfall. We set up very regimented point a point B Point C processes where there are specific wiki games that we have to go through to get there as we develop and create more agile cycles and more Agile development. The security practitioner tends to Revel in structure and process and we Revel in structure and process because it's measurable is scalable.

It's controllable and understand that a security program is nothing but an implementation of multiple controls within the environment and we have been slow to come to terms and say how do I create controls that have equal efficacy yet can still flex and scale and create agility all the while honoring the need for the developer to go fast and understand that I'm not trying to create friction within your environment. But I'm trying to create a balanced risk management approach that allows you to put out good quality secure code quickly and as swathi indicated in the past half decade at least we've gotten phenomenally better at that. We're not perfect but we've gotten phenomenally better at that.

I think. ah, fantastic so let's um, let's shift the conversation and get really practical because for anyone listening to our conversation and thinking to themselves. Okay.

I would love to buy into this idea that you can have security and speed but maybe folks are joining us who've actually just never seen it happen before. Kim and swathi Kim. I'll ask if we can start with you tell us about Practical approaches to security testing.

How do folks, really? Do this. Okay, I'm probably because as I said, I'm not a developer and don't play one on TV.

I'm probably gonna start at a more stratospheric operational level and then swaffee given your background. I'm sure you're gonna be deep diving more than I can or more that I can with any level of credibility. So I like to take a look at basic principles within the environment that I try to implement as I put in programs.

So one I start with standards and move from there. Yes, the bad guys are coming at us so likely and a gazilliona one different ways. I can't solve that.

You could Julian in one problems and create speed and eliminate friction. Let's first start with what are the standards and principles in terms of what we're looking at what we're doing what from a risk perspective do we want to get in front of if I'm building a development program for web-based applications. It sounds Corning, you know, we'll start with the Awash top 10.

Let's just make sure the basic fundamentals out there. Yes for higher risk applications. And as we develop that muscle will go further.

But if I can give you 10 things to look at and 10 things to solve I can then hopefully create at least a minimum set Baseline that I can build upon that I can educate my developers about and that Can be proactive about because the more that they know the more that they own the less friction I can create so let's start from a standard and let's move from there. I like the idea of being risk based. There are a lot of books out there right now in terms of measuring things how to measure everything in cyber's one, but I go back about a decade to a guy named Andrew yakim who wrote a book called security metrics.

There is a great reference in there about what I what he calls an application in security index and it's a graphic within the book and it's something that you can give a sales guy to fill out for an application and it's multiple choice, you know, is this internally externally facing check one? What type of data is it going to hold and explain English the data, it's gonna hold and a list of questions and depending upon those answers you score the app. If the app has a low score it's internal something we've done before with no sensitive data great.

Why the hell do I need to spend a lot of security testing and evaluation proactively on that. The relative risk level is low. I would rather do some minimum necessary stuff because I want to make sure things are at least minimally secure and get that out the door.

So the developer can do the next step. If I'm at the high end of the scale, excuse my language, I'm going to use security proctology and I'm going to make sure that I test this thing to the hills within the environment as much as possible, but we have a collective tendency to treat the first one and the second one identically and that can be very frustrating and slow things down. So take a risk-based approach to your testing.

It may not it may be a little more arduous. That's the wrong term but a little more intricate I think to implement but you'll eliminate friction and start spending your resources where they need to be I do like the concept of security is code. I think it's an overused term that is not being used appropriately within the environment.

But at a bare minimum I look at security as code to say for my biggest risk and biggest things out there. If you take this little code snippet and use this I guarantee you you'll close the gap in that let's create that git let's create that library and use that code as we build within the environment that is another way. We can now reduce first in the environment be proactive without slamming into the security Wicked gate at the front end.

And then the last thing for me is to create ownership amongst the development developer community and you can head fake that and I'm now going back to again when dinosaurs roamed the Earth in the early 2000s where we're doing applications security testing tool based testing based upon the nature of the code, so I had to development shop and I said, okay. I'm gonna buy this tool. And I want to make it simple you run your code through the tool and a split spits out stuff that says either red Amber green the security standard to rule code and get us to sign off and it's simple no Reds if there's a red in the environment.

Someone has to risk accept that it needs to go away. And you my developer team can actually run this tool. You don't have to wait for me to go do this.

So before it gets to me and you get frustrated when I take it back. You can run the tool as often as you want. I'll buy the licenses.

I'll pay for it. Great. Because the head fake is then the developer comes to you and says why is this thing called cross site scripting bad and you sit down and have a conversation and say let me explain to you and let's talk about how we can do that.

Then you get the development lead to come in and say, you know, we're seeing a lot of problems with X. Would you be willing to have a training session of some sort to help us become better coders and you say great happy to do that. I'll buy the pizza then you get people coming to you and say but why are we letting this thing through is yellow?

It should I think that's a great idea. So you create that sense of ownership up front and it makes it easier for us to partner with the developer Community versus we're the ones who are saying no and if you think about it, The head thing here is those principles amount to what we want to achieve and ci/cd anyway. So if you're doing these things you create a good robust the ICD environment and then it's just a matter of how we Implement and how we execute so from a stratospheric level.

For me, those are the basics you do those things you can get there and I will happily handle the floor over to use coffee to talk about how you operationalize that. I'm gonna interrupt before we go to swathi. I just want to make sure that folks caught a reference that Kim put out there.

He talked about Andrew jakewit's application in security. Index Andy Jake with published his book security metrics replacing fear uncertainty in doubt in 2007. Excellent book highly recommend.

Also fun fact Dan gear wrote the forward for Andy's book. Andy wrote the forward for my book which was published in 2011 and realize that yeah, super fun and cool and weird. Check out check out the book.

It is a classic, you know, the the concepts definitely stand the test of time swathi. Tell us what you think about practical activities that folks can do to do speed and security. Yeah, I think you know one of the examples I want to draw from is what Kim was talking about, you know application risk grade like being coming from sort of the Oracle SAS world.

That's the mission of our team right? We have various applications and how can we have? bought quantitative and qualitative kind of methodology for risk and I think one of the things I would add to that Risk Index would be the revenue that the app generates and of course the customer base and the user base, you know number of people that use it becomes quite relevant when you're tailoring tailoring your average program for for the company and I was thinking, you know, I was I was I was draw from like couple examples, right?

Like let's talk about pen testing versus red teaming versus stepped hunting rate. So when you think of, you know practical approach to security testing all these three sort of security pillars to some some type of security testing, right and I think especially like pen testing and red teaming I've seen like throughout kind of my career sometimes like a lot of confusion around and they the same why do we have different findings? Right?

Like of course penetration testing is about looking looking at the environment and attempting to discover and as many vulnerabilities as many misconfigurations as possible, right? And then you know when with the goal of the goal of the Prime test is to find as many gaps as possible, but with the red team engagement it's to find one way in and one way in an exploit that right and when you when you look at that hunting, of course A different types of thread hunting hypothesis based, you know Intel based structured unstructured, but in general you can look at what's going on across your across your environment and also externally, right like what are some of the companies have been breached. What are the tools and tactics and ttp's procedures being used and how can we look at that breach then working backwards to find their more of access and then try to find that in your environment.

So you're hunting for things. So in each of these examples, You performing one way of doing security testing and all three are essential as we're kind of building building a more holistic, you know security program and model. I think the results from each of these are quite valuable and they're also different form of security testing with each of these disciplines.

So I think that would be kind of my I guess practical tip to say look at all three Avenues to build a stronger program. I'm thrilled to hear your description of these different approaches swathi and it actually reminds me of when I was at digital digital later got acquired by synopsis and I was performing these some assessments be some stancer building security maturity model. It's a scriptive model and software security, you know, these types of activities would be in an umbrella called defect Discovery, you know, the very basic idea being We got software.

The software is vulnerable find the vulnerabilities so that you can fix the vulnerabilities. Tell me if I understood this correctly swathi the the three that you talked about just here pen testing red teaming threat hunting do I understand? These are all types of defect discovery that actually require humans to do it.

This is not the type of thing where I can install a software program, press a big green button and it'll go do these things for me do I understand that correctly? Yeah. No, I think that's a great kind of way of you know, this was a new term for me.

So thank you for talking about different Discovery. Yeah, I think definitely I think that seems like an umbrella term but all of these different approaches could be combined. I think that is both a manual and an automated aspect each of these right like for example, like there are multiple, you know, red team Frameworks.

We know the miter attack framework. There are so many tools out there to perform that they're hunting to do the scanning to to do the the Fantastic or Web application scanning. So there are tools out there.

But of course that is definitely manual intent intervention required and I'm yeah, I'm sure we're gonna talk about that. So I'm kind of excited about that too. Yeah.

Wonderful. Let's do this. So, you know I think that as Security leaders the jobs that we and our teams have can be challenging and yeah particularly with regards to defect Discovery.

I would love to hear your thoughts swathi on kind of You know, how have you seen? Automated testing be used effectively. How have you seen?

I think you you told us about some of the manual security testing. And then how do you think about? One or the other do you think for example one or the other is good enough.

Do you think that you know, how should an organization think about it when they're trying to decide do I do automated do I do manual do I do both? How how should we think about this? Yeah.

I wish I wish that was an easy answer and the typical response is gonna be Independence, right? I guess extending from my previous example, depending on the organization definition of testing and I think you touched on this previously Caroline to say money resources, you know, those are some of the other constraints like Is the the program funded to we have people with different skills had to do this? And so for example vulnerabilities scans, we don't validate vulnerabilities right not nor will be fined unique methods of attack through that and I will say I'm sure some different places might have set this up differently and so vulnerability scan should not be should be sort of, you know, the first approach or not as much as the Final Approach.

So to say so once scanning is relatively I would say easy to automate and and just like him I'm trying to be spicy here. I'm gonna throw some direct direct statements. I love it.

I love it. you know that's generally relatively easy to easy to automate right like you set up the scan you perform it on a weekly monthly daily, whatever basis, you know, let's consider third party penetration testing right like set up a Dev environment test environment, you know, we get a third party to kind of do the validation to do the testing we get the report and I think the complexity comes in when it comes too late task tracking reporting metrics and generation and dashboard. Of course, there are tools out there that have automated this but when we have such variability in the environment, right, like for example Oracle, we have be support commercial clients government clients, you know specific, you know secret regions or we have dedicated multi-tenant and single tendency.

So when there is that much complexity in the environment and variability in the environment really dashboard metrics mittiation becomes a becomes becomes a challenge and then you know, so we talked about once scanning pen testing and then on the right team that team kind of carefully probes and explores and you know exploits these unique bugs, right? Of course, these are so so specific to the environment. And there are standardized industry modules and packages but we still need it's particularly hard to automate that right like we still need to find a way in that's why we have open-ended, you know wide kind of offensive engineering engagements to do that.

instead of we have to live we need for their automation there. Right but forensics analysis, we can use our scripts to pull this can pull, you know, endpoint artifacts, but we still need kind of manual analysis to go through the results and like make make a valid statement or come to a conclusion. Right and tools can help with that.

So yeah, I think I would say depending on your environment both can be useful. I think automation can be leveraged heavily in a few areas. And I also think that at some point with the automation we are gonna hit plateaus and then it's gonna be small incremental improvements to kind of take the security program to a more mature state but still, you know, yeah, very important.

So that's kind of my high level view. Yeah and mind if I mind if I pile on please do so I realized one of the things I want to observe it is easy for us with companies behind us such as Intuit Netflix and Oracle to talk about the vast array of resources energy Etc that we can put towards a problem. And I have those vast energy resources and array, I would absolutely put them all towards the problem.

I am all towards the problem here. But there are a lot of folks who don't and figuring out what to do within that environment can be difficult agreeing with everything swathi said regarding it depends and trying to avoid words that make technologists cringe such as oh, I don't know risk management because they roll their eyes at that because doing that calculus can be difficult. One of the things that I and a few other ciso are former see some but a few other cisos that I know have been working on one of the things that I've been working on in.

My teaching Endeavors is this concept called the economics of security. We collectively Don't Run Security as a business it costs. Us to do certain things it cost us just in terms of Manpower and man-hours it cost us in terms of tools that usage.

Every incident has a dollar amount that's associated with it conversely every delay in the code Beyond this initial exception Point costs as well. And one of the things that I try and trying any more holistic Viewpoint to look at is to try and make this an economics decision because at the end of the day that economics decision is de facto the business decision and let's get out of highfalutin. The sky is going to fall and we're going to be hot and dogs and cats are going to rain from the sky and everything else associated with that on the security end.

As well as the developer and we are going to lose 10 quintillion dollars against the quarterly earnings if I don't get this code. out two hours despite the fact that I've taken all the actual testing time that was allocated and we're not ready yet. Both, I'm sure none of those things have ever happened or developers a security folks in your organizations have never said those things or their equivalent.

Let's get out of that and just begin to understand the economics we're talking about because yes, the best solution is the one that balances the economics of the potential of a violation versus the delay versus the cost of implementation. And as we deal with things like Ai and ml coming on board those economics be tilt in our favorit. They're not going to be a Fantasia, but they will tilt in our favor towards automation.

But we also have to handle the overload associated with that. We forget that if I push a button and find out this problem, I have to manage and metric and solve that problem going on and somebody's got to be looking at that screen to do that. So I don't think we're ever gonna get away from Full manual interface, but automated testing versus manual testing.

What are the economics say, if the economic say that right now, all I can do is buy this machine scrub my code through this, you know through through this service and eliminate the Reds economically. That's all I can do. That's I can do you know, if economically I can put together the teams that swaffey has described and similar teams here.

Then let's talk about the economics of that looks like versus the area. So I think collectively both sides of this equation. Nick need to get away from hyperbole.

And look at the economies and then see what you can do and do what you can that makes sense within the economic framework. very cool Thank you, Kim, you know. I could talk to you too about this stuff literally all day.

I cannot believe how quickly the time has gone. We actually have just about five minutes. And so I had planned to ask two more questions.

And what I'll do is I'll sort of bundle them together and we'll try and do it both at once. So the last swathi first and then Kim. part one What are common problems?

that organizations run into when they're trying to do security at speed and part two What advice do you have to kind of close out our session today? Yeah, for sure. I think the common problems sort of what I've seen is if I better summarize it.

While you the number of you know findings that come from these security testing the volume is huge then remediation timelines, right? Like how can we have a great partnership with the security teams and other engineering teams to figure out what's the reasonable time frame without risking risking the business the operational Bird, right? We've seen you mentioned say they've been so many more, you know, the operational team has been burdened with these many type of attacks and trying to clean up after that and so are the SRE teams engineering teams.

So if the consider kind of the operational burden that these findings intermediating this identifying risk is easy greatly mitigating that is is the is the hard part and interestingly as I was thinking of summarizing this speed is not one of them. I think to Kim's Point our our tools have EV To that, you know we are we're not able to catch everything but we're able to keep up with the speed. I think it's the other Downstream things that we need to be.

We need to be good at and what advice do I have? I think I have three main points to make here. Let's centralize sort of security asks, right like our partner teams.

They say Okay are one management team is coming to me with security ass or compliance team is coming to me recipe is coming coming to me. There is an incident happening. I need to support that so there are different points of contact and I think it's very easy to burden our partners with all of these asks.

So let's try to centralize kind of security asks there have been there has been a lot of talk, you know around building Partnerships with the engineering team so I won't touch that but of course we need we need to do that. Um, the second point would be build automation for follow-up rate. All of us hate hate nagging we don't want to be like, what's the ETA whatever even this what's the fix?

You know, are we exposed? So let's build some kind of automate automated mechanisms to do that. And then let's change or adapt our severity ratings to consider environmental variability, right if there is a CVSs score whatever score of 10, but if there are only five systems, you know, we need to be urgent but the scope is lesser same thing if there is a finding out there but it doesn't directly impact our systems.

Like is it fair to put it put it put it a high. So consider environmental variability would be three three points. I would want to make Fantastic, thank you Kim.

You've got it's I want to make sure that I will do today. I will do I will do it in one one the first part of your question what swathi outline for me was what I effectively called Ready fire aim, we have a lot of folks who want to build testing programs without understanding process burden overhead Etc taking the time to methodically think those things through eliminate some of those problems and not just say we need testing bam. Let's put it in here and the start breaking stuff in terms of things to think about one start thinking about both and regarding to speed and security versus either War.

I believe developers you want your code and owning your code means owning all aspects of your code, including the security of that code. So you need to understand that part of that is ownership on you Security Professionals, you're part of the business you should be committing to speed and as frictionless as possible a way to allow your developers to put that code out the door in a timely fashion to serve. Shareholders and stakeholders lastly from an organizational standpoint stop creating levels of compensation and standard across the board that can create toxic friction between these two having developers compensated for going fast and not integrating security and having Security Professionals compensator for being secure and possibly having to put up those Gates creates a toxic level of friction within the environment leaders start leading fix the problem there.

I think I've got 30 seconds left. I'll shut up. Thank you both so so much for sharing your experience and your wisdom with us today folks.

If you are watching this session, and if you enjoyed hearing from us, please don't hesitate to follow us on LinkedIn. I know that we'd each be very interested to continue the conversation with you. We have like 10 seconds and I'll just leave us with this for fun prior to starting our session today.

We were talking about spirit animals and I'll share this with our audience just for fun swap. These spirit animal is the Scorpion. Tim's spirit animal is the bear.

And my spirit animal is the lion. Thank you all so much really appreciate it. This was so much fun.

A lot of fun. Thanks for having me. Thanks for having me.