Running Security For A Security Company With Michael Hanley

[0:01:16.9] Guy Podjarny: Welcome back to The Secure Developer. Thanks for tuning back in. Today we have a guests that deals with security both in his job and the constituents I guess, those he caters to and that’s Mike Hanley who heads up security at Duo. 

Thanks for coming out to the show, Mike.

[0:01:30.2] Michael Hanley: Yup, thanks for having me Guy, happy to be here.

[0:01:32.5] Guy Podjarny: Mike, before we dig in to the variety of topics that we have to review, can you tell us a little bit about yourself, what is it that you do and how you got into security?

[0:01:42.8] Michael Hanley: So, I’ve been in IT for roughly 20 years now, got my start at Electronic Data Systems, working really strictly in my systems administration, moved on later after graduate school to work primarily in the Defense Department and Intelligence community space where I got to work on a lot of what I would call sort of the 1% security problems, wealth on resource, very specific and kind of bespoke issues and problems that – when I found Duo in 2015, decided to join the team here and really focus on democratizing security in a mission where we’re much focused on solving security for the 99% and sort of the most ubiquitous sets of problems around to take over end point security, et cetera.

It’s sort of been my journey leading up to here and of course, worn a couple of different hats in my time at Duo but that was sort of a lead up to joining the group here.

[0:02:27.3] Guy Podjarny: Very cool, I guess almost taken the brains of the government and kind of spreading that learning and building it into the solutions themselves.

[0:02:35.8] Michael Hanley: Yeah, that’s right, it was good because when I joined there, I was coming from a very applied research and development background and my first job at Duo was actually not running the security team but rather kind of running from some of our – what duo labs program, if you’re familiar with some of the open source projects that we’ve released there.

I spent some time getting that team off the ground and really focusing on what’s our sort of A team at 36 month strategic technical set of projects and exploratory work that we need you to de risk some of the opportunities in the space but later on transitioned into running the rest of the security program here.

[0:03:06.1] Guy Podjarny: Very cool, it’s an interesting kind of transition there. You were building I guess this is the maybe per core related to the fact that Duo is a security company so although the work you we redoing was not – didn’t have security in its title, the capabilities that it offered was security so you built kind of that expertise, is that the way to think about it?

[0:03:26.2] Michael Hanley: Yeah, really, when I started here, you know, we were thinking primarily about applied security research and development so what are the emerging technology opportunities or techniques or techniques or capabilities that can strategically advance what our customers are receiving form us, you know, security RND to start.

But then, over time, it really just sort of naturally started to build out the rest of the functions that you would need the security programs. We have labs and a stable place and then started building our application security engineering function or corporate and cloud security function or compliance function from there. It’s sort of a natural horizontal expansion of the fleshing out the rest of the functions and seeding it with the existing competencies and capabilities that some of our staff had.

You know, that whole build really ran from, I would say, you know, mid-2015 when I joined to say we kind of full operating capability across all of those functions by you know, late 2017 or late 2018.

[0:04:16.1] Guy Podjarny: Got it. What does the org look like now? Today, you had sort of security at Duo, what does that look like in terms of different aspects of the team.

[0:04:27.1] Michael Hanley: Yeah, we haven’t really organized around a couple of the different areas. First and foremost, we continue to have a research function. It is important for us to stay ahead of where our customers expect emerging threats, changing technologies in the landscape, you know, availability of new pieces of hardware and software that might change the ecosystem in which our customers are operating and trying to secure their own businesses.

So we spend a lot of time and energy in making sure that we’re ahead and being a market in that space so that’s really where our Duo labs team continues to operate and we have the function largely around  how do we make sure we enable our engineering team to build and deliver secure products, that’s our applications security engineering group.

Their customers are the engineering and product teams and enabling good outcomes at the edges there. And then we have our cloud security team which is how do we operate those products that we build and deploy securely and you know, provides all this sort of traditional what you would think about detection engineering and response and operations pieces of the security group.

We’ve got a dedicated compliance function as you might imagine, running security for a security company, you’re generally going to be in a lot of situations where customers are asking you to prove or provide evidence or attestation to how you’re securing the products, how you’re securely developing them, how you map to various regulatory and compliance standards and really importantly to our customers, how we help them achieve their compliance and regulatory outcomes through the uses of our products. 

We’ve got a pretty substantial investment across all of those areas when you think about the functional layout of the team. There’s a great deal of advantage to having them all under one roof though, which is, well, we have those teams functioning organized.

There’s a tremendous amount of cross functional collaboration amongst the teams and we really think about it as what are the right people to get the right jobs done regardless of what their home team in the org chart is. The org chart is a way for us to sort of rationalize a big team and group work but ultimately, we want the right people working on the right outcomes for the company or customers.

[0:06:22.6] Guy Podjarny: It’s a very unique, I mean, we have this at Snyk as well, I’m maybe a little bit more familiar but it’s a fairly unusual choice because you’re a security provider and so you’ve chosen to kind of put those two groups together, right? Instead of evolve it from securing others to securing yourself but having cross pollinating between those.

What would you say like around the practices of the groups work together, I guess they enrich one another, you know, first of all, do you see transition between the team, do you see people moving from like one side of the fence to the other? 

[0:06:53.2] Michael Hanley: Absolutely. 

[0:06:54.9] Guy Podjarny: Kind of move around.

[0:06:55.4] Michael Hanley: Yeah, absolutely, we’ve had examples of all the above plus we’ve had examples of actually incubating net new functions in the security team that have then sort of graduated in other functions of the business. An example is, actually, our data science team, we initially hired a leader for that function and incubated that under the Duo Lab’s umbrella so we thought about that as a net user strategic RND function.

Over time, what we discovered is s we grew that team up that there was some natural efficiencies that could be gained by grouping data engineering which is sort of thinking about pipeline, the system’s bust between a lot of different storage systems and learning systems. Putting those groups together so they’re working collectively on our product objectives and one group. We actually fund data science out and into engineering where it now is sort of the whole data science and engineering group in that team.

We’ve had transitions of people, transitions of teams and ultimately, we’re always very open to sort of what’s the right thing to find the intersection of what are people interested in, what do they want to get better at and what are the jobs that get done for the business.

We really try to optimize the intersection of those things to make sure people have fulfilling challenging and clear growth pass ahead of them.

[0:08:04.4] Guy Podjarny: That sound like kind of a thriving surrounding to be in. When you think about delivery, I guess you know, for these different teams, you know? I guess labs has its own delivery mindset, right, probably a little bit more for the horizon. Might have the people sort of securing yourself. I guess, how much sort of customer orientation, what’s the methodology that you use to manage activity inside this security teams?

[0:08:26.2] Michael Hanley: Yeah, really, all the work at the end of the day should be focused on what’s good for our customers and what’s good for our internal clients that are in other parts of Duo’s business. We think a lot about how do the company’s values, being easy, effective, trustworthy and enduring, apply to the things that we do inside for other teams inside the business.

While we have many of those functions, you know, I mentioned a few of them where we talked about sort of how the org is designed. At the end of the day, I don’t actually expect or necessarily want anybody else in the company to have to worry about how they get work chart. What I would like is they have one front door, check on for the security team and ask for help and I know that when they do that, when they ask for help with an issue or have a technical question or curious about something because of course it’s valuable for us to have a culture that’s curious and interested and security topically.

We want to make sure that it’s easy for them to get an answer for us that we can deliver that in plain language in such a way that it helps them get their job done and the types of things that we’re doing for other teams if it’s building a system, a tool or something to help make their job easier are enduring so that we’re not constantly causing them to suffer from contact switching as we change out tools or pieces of our stack, et cetera.

We really wanted to be ultimately easy for them to take security as part of their job responsibilities and execute well on their primary job function. Ideally, if I go up on stage at a company meeting and say, “Who here is on the security team?” I should get seven, 800 hands from the whole company. That’s really kind of a cheap measure of success for us that people think of themselves as an extension and as a member of the security team and their day to day execution, whatever their day job is.

[0:10:02.1] Guy Podjarny: So Mike, when you work with these development teams, right? Or you work with other people in the organization and then, how do you keep incentivizing them, right? Or how do you keep kind of keep them engaged in this desire to be a part of your security team, you know, and feel good about it?

[0:10:17.2] Michael Hanley: The best way to do this, and the cheapest way to do it is really to focus on reliably identifying, surfacing, and celebrating good security behaviors and good security hygiene. We have a friendly neighborhood security bot that reaches out to people on chat and says everything from, “Thanks for updating your phone to the latest release. You are one of the first few people to do that. You’re doing your part to keep us secure,” to providing, in some cases, sport bonuses to people who raise their hand and say, “Hey, there’s a problem over here and I want to be in front of it from a security standpoint.”

So, it’s much cheaper in the long run for you to focus on identifying and reinforcing what those good behaviors are and making it very visible what the desired behaviors are compared to going around and chasing people with a stick. Nobody wants to be chased with that, but they would much rather hear that they did a great job and have examples of what the organization expects and desires from them behavior-wise.

 

[0:11:13.2] Guy Podjarny: That’s awesome. Do you think actually is that bot, you know, are these things you’ve written about? Or sort of you have published anywhere? It feels like everybody should be using the —

[0:11:22.2] Michael Hanley: Yeah, yeah. In fact, I should probably write a blog post on this. But I’d say, if you ever see a Duo employees laptop in an airport or at a conference, one thing you’ll note on there is, you know, people love stickers. So even little things like the first folks to report a phishing email that come in to the security team will sometimes give them a special kind of edition sticker that says they were the first to report a phishing or attack campaign on the organization. Again, just to recognize the importance of them executing on their day-to-day security responsibilities and helping them realize that those things are not trivial, and in fact, we love hearing from people when they have questions and comments. It shows that the extended sensor system is working well and people feel empowered to execute on their security responsibilities and it’s their contribution that matters.

[0:12:06.2] Guy Podjarny: That’s awesome. I think any good rewarding system should definitely involve stickers. So I think that’s great. 

I love the, sort of two things that you said here that I very much like, you know, like one is indeed the customer orientation, you know, sort of the thought of the security organization as a supported organization as a service provider to the rest of the org, you know? As opposed to like a naysayer or you know, whatever prison guard to try and sort of enforce it and the second is just that emphasis about make security easy.

[0:12:35.0] Michael Hanley: Yeah, both of them feed very much into the idea that especially in a SaaS business ass you well know, Guy. You have teams that are continually shipping new code, deploying new services, setting up new instances and setting up new instances and your cloud environment. If your objective is to be in the way or a blocking or negating function on every single one of these things, that is a losing strategy relatively quickly.

Both in terms of the hearts and minds of the teams that you’re trying to support but also the velocity to businesses such that you’ll never be able to actually keep up with that and you sort of get into a place where your investment strategy get out of whack from the security standpoint.

You know, the best metric I think for us is that people continue to come and ask for help and assistance and ask questions to do their job better and that means we are reliably delivering good customer service to them.

[0:13:16.6] Guy Podjarny: That’s awesome. Let’s dig into that a bit, we’ll talk a little bit ab out maybe the work with the development team. What is it? How does your team engage with the development team as capabilities are built and assessed? How do you split those engagements?

[0:13:31.0] Michael Hanley: Sure. So, for the day to day software engineering work that we’re doing, at the genesis of a new feature or a new idea that we want to deliver, generally, there is an intake process where the app tech team and the product management and the engineering leadership have an opportunity to discuss.

You know, what are we trying to solve for and what’s the level of engagement or support that the security team can provide to make sure we give the engineering team a higher degree of assurance and confidence that what they deliver will be secured in me, both security expectations of our business and of our customers and you know, that tends to vary, I mean, some engagements are very just sort of informative only in the sense that it’s like you know, thanks for letting us know and we’ll be here if you need anything.

Some of them are much more embedded and attached or we might be continually sort of assessing a broader project throughout or you know, directly contributing to the codebase for building tools and automation to support execution and some of the other client teams.

But you know, generally, that’s an agreement between the security practitioner that’s involved along with the engineering and the product leadership. There’s another engagement model too of course which you might expect which is around, in the event of a product security incident and fortunately, we’ve had relatively low volume of those but everybody has to maintain good piece practices.

They’re sort of an outbound practice whereby, when we have a defect that’s disclosed to our team, whether it’s by a customer or researcher. We will proactively engage with the engineers and product managers to bring in the right folks to validate the report, identify what the potential solution is and work together on getting it fixed out the door.

There’s really sort of you know, a couple of different engagement models to get into that. But I’d say, at the end of the day, what makes all of that work is, everybody has a good shared understanding that the security of our customers depends on us delivering secure and high quality software and I think nobody have used security as the security team’s problem.

US is helping make it easy for the engineers to deliver, quality and secure software to really focus our energy on – we’re making sure everybody has that and that sort of greets for all the rest of the engagements.

[0:15:28.0] Guy Podjarny: It sounds like you know, sort of I understand the flow I think and I’d say, in a lot of the cases, the initiative comes from the development team, they build something, they want to, they reach out to you, you help them out our you – even the sense of how involved the security team should be is part of the development or change to this capability.

On the other side, you’ve got kind of the response side, you got a probability report or something like that, it sounds like you take the lead over there and you engage the dev teams instead of on the other side.

[0:15:55.2] Michael Hanley: Year, that’s correct.

[0:15:46.3] Guy Podjarny: In the middle, there’s like security automation, if you think about like a secure pipeline and things like that, is that something your team builds, is that something the dev team builds to support, how does that work?

[0:16:05.1] Michael Hanley: Yeah, substantial amount of the tooling that runs in that middle space that you described is built primarily by my team, we’ve actually open sourced a good chunk of our security alerting stack on our GitHub page but you may have seen tools like CloudMapper for example that we’ve really switched solve problems that help our engineers but also other parts of our organization, reason about how does our software look in a deployed context, how do we make it easier to think about or guys in our production services or where do we find that we’ve got other challenges like for example.

You know, an architectural scaling weakness. We build a lot of tools to help figure out some of those problems for the teams as well. 

[0:16:43.4] Guy Podjarny: This is by the way on GitHub.com/duosecurity, right?

[0:16:46.6] Michael Hanley: Yeah, I believe it’s the /duo-labs site. I can put it in the chat here.

[0:16:51.8] Guy Podjarny: Cool, yeah, we’ll post that link to the show notes. Cool, you build those notes, you open sourced them, even better. You know, I would like to – you build these tools and share them around.

[0:16:58.6] Michael Hanley: The theme that you’ll notice when you look at those tools is like if you just pull up a GitHub page and just look at sort of the top view, you know, CloudMapper is helping people sort of reason about the total composition of their environment, Parliament, sort of the next one on the list is all about minting AWS I impulse it to make sure that engineers don’t inadvertently shift, misconfigured or ineffective IM policy. Many of these things are not about making it harder for the engineers to do their jobs, it’s actually about sort of obstructing away some of the complexity or otherwise security challenges that came in from some of these areas which is build tools help them solve those problems.

[0:17:33.5] Guy Podjarny: Perfect, and that’s precisely where I was going which is you know, are these designed as well to sort of self-serve I guess by developers. Presumably, if a development team is using CloudMapper, they can use it without needing you in the day to day use of it and you use it to sort of govern or understand or you engage with them on it when it’s something deeper.

[0:17:51.2] Michael Hanley: That’s right.

[0:17:52.4] Guy Podjarny: Okay, very cool. I need an address for clarity, it’s GitHub.com/duo-labs.

[0:17:55.6] Michael Hanley: Yup, that’s right.

[0:17:57.8] Guy Podjarny: That’s the right link that’s posted. Cool, this is so you work with the dev team sounds super healthy, do you align like is your – you mentioned before that you don’t want the development team to need to know the exact way that you build your organization, is there an element of partnership or like do they have some constant person that different dev teams would approach? Is it a ticketing system? What’s the actual kind of approach when they want to engage, what do they do?

[0:18:23.6] Michael Hanley: Yeah, good question. You know, we go to where it’s easiest for our engineers to work in terms of how we engage with them so for example, using the same ticketing systems so that we use for source control and the rest of our engineering cast tracking, we tend to do a great deal of work with our engineering teams in those same forums to make it easier for them.

We also focus a lot of energy on some of the tooling interfaces and you can – furthest from some of the content our GitHub site, plug in to natural elements of the workflow where it’s easy for engineers to get feedback, for example in the build and deploy process, those are places that are further to the left than us reacting to something that’s already been pushed out to our customers or something that we might get out of an audit.

There’s generally a drive to do work where our customers and clients are operating and do that work as far left into the development life cycle as possible, A, because it’s less expensive for the business and for engineers to do that. But B, it’s also an opportunity to help and provide good calibrate and feedback much earlier on a cycle that is likely to lead to good design outcomes.

[0:19:24.1] Guy Podjarny: Cool, it sounds like an awesome system so I’ll kind of ask you a bit of an unfair question, given that you have such a great handle on all those. How do you measure all this stuff? How do you know if you’re doing the right thing, if it’s working, if it’s not working?

[0:19:39.9] Michael Hanley: This is a great question. I am really glad that you asked this question, Guy, because I generally have a real problem with security metrics and then volumetric sort of bug counting and things like that. I think that those are not really sophisticated enough to describe but many programs and particularly in ours, Mark Sanesaw who is our app sec lead has done an awesome job of thinking about this problem and instead described where we’re at for app sec as a maturity model. 

And this is helpful for a couple of reasons, one is if we solely relied on defector reporting or how often we needed to release a security advisory to our customers, in some cases it might be a year that we go between having to release the security adviser feed or many – when you have that long of a time lag to getting feedback that is not necessarily indicative of success of your program nor is the absence of evidence that there is a problem sufficient to communicate that your program has been successful. 

So the maturity model that we use at Duo is really a mash up of the BSAM and SAM if you are familiar with those two models and we try to think about what is key metrics that come out of that or what is the percentage of activities and that combined model where we have at least partial coverage and what is the percentage where we have full coverage and this is helpful because we can use this to drive continuous improvement. 

And we can also make recent decisions around we are not going to do this activity because we think it is a low priority for our business but we want to make sure that the high priority activities that we have in those lists are things that are doing well or approaching mastery in those particular areas and it is also helpful too because we might decide quarter over quarter, we maybe didn’t focus enough time on a particular activity and we can dial the score down on that. To make sure we are tracking and continuing to invest in that following quarter. 

[0:21:17.7] Guy Podjarny: So maturity models have a lot to sort of say for them, you know there’s two primary critiques about them. One is they’re sort of often times not super detailed, right? I know you can put a testing tool in your pipeline and chuck the box if that is what you are trying to do in the process, right? So do you have any more grand letter there and the second is they sometimes people sort of imply that they are done that at some point you’ve grown up. 

You know you are mature and you don’t need to do anything when the reality is it is a bit more continuous. So how do you think about those two challenges within the context of maturity model? 

[0:21:51.1] Michael Hanley: Yeah, good question. You know in total the number of activities that we track in our maturity model, I believe is a little over a 180 across a couple of different domains. We tend to be harsh raters of ourselves. So unfortunately we are not in any danger of believing that we’re done, which is a good thing, but we do still compliment that with an understanding of what is our defect to rival rates and tracking that to make that things like that have scaled sub-linearly against the growth rate of our codebase for example. 

To make sure that we are continuing to still deliver at a high quality software but also part of the reason I mentioned percentage of activities with partial coverage by domain is we are not necessarily always shooting for complete or done in every single activity. There are potential low yield activities that we would like to be doing some of but not necessarily having a complete mastery yet. So I think there is a couple of different ways to track both the softer things like the maturity model with the harder things. 

Like the actually counting number of defects, number of alerts, etcetera but we take a complete view of the two overtime.

[0:22:54.6] Guy Podjarny: Got it, yeah that makes sense. It makes perfect sense. Can I veer you off a little bit to the side and talk a little bit about the cloud security. So you know I find cloud security fascinating, is it dev minded if it is not made for the infrastructure, how do you define when you’ve got your products as an application security teams, right? You had mentioned in the beginning a new cloud security, how do you define that divide and for instance, who owns the containers in this context? 

[0:23:18.2] Michael Hanley: Yeah, I would look at it if I were to map against the software development life cycle that we have at Duo, I would say to the far left time horizon we’ve got where the labs team is engaging and part of that is strategically identify new technology opportunities but also it is to define early what good security design parameters would look like for some of those teams or in many cases like for example touch on things like password and result authentication. 

I am sure you have heard of an emerging standard called Webothen. This is something that we work on not just to make sure that we are ready to actually implement and deploy it when the time comes for customers but also to make sure that we really understand all of the security properties of that and how to make sure we implement them with a high degree of assurance when we choose to product test things like that. 

So part of that investment starts really all the way in the applied research phase. The app sec team is really focused on as we are doing the work between product requirements and functional requirements to something landing and master where the build is green that is the set of activities that occur there and then cloud security and cloud security architecture is really sort of what is the deployed context of that software and the infrastructure upon which its riding. 

And how do we actually secure those elements of it. So there are some sort of natural passings of the baton if you will between those phases. I would say that is something that we spend actually quite a bit of time tweaking because as you might imagine you do especially in the second of these two transitions between app sec and cloud sec there is not really a fine clear handoff in all of these cases and in many cases it is fade in fade out between the two as we get into that phase of things. So that’s generally how we think about mapping those across kind of the development timeline. 

[0:24:56.2] Guy Podjarny: Got it. That is actually one of the crispness definition of the division that I have heard and I guess it does imply or require that those three teams collaborate between themselves very well right? 

[0:25:07.1] Michael Hanley: Yeah, extensively. In the cloud security team too I would say I shouldn’t cut them short because they do quite a bit of work for their left thing the SDL as well because they are responsible for many cases for the security of the other environments in which we develop. So app sec for example is not responsible for the security developer workstations and some of the security tooling that allows them to confidently commit software for example to our code repo. 

A lot of the other supporting guard rails that go around that come from the cloud security team to provide the necessary supporting infrastructure to make sure that we got a relatively high assurance software security supply chain leading up to being ready to actually deploy that. 

[0:25:45.5] Guy Podjarny: Got it. It really is awesome. I love the structuring and the attraction between the different entities. Maybe use the opportunity a little bit to talk about the broader Cisco world. Like you built a lot of these stuff probably in Duo, sort of pre-acquisition maybe we’ll get past, how does it work across Duo? How is your security approach, different maybe to other teams that you do collaborate? 

[0:26:09.1] Michael Hanley: Yeah so as you mentioned, we were acquired by Cisco. The deal closed in the fall of 2018 so we are coming up on a year and a half now. One of the things that is interesting if you have gone through a very large acquisition is if you strictly think about the acquisition that has an acceleration of revenue growth that is probably a short sided view of the opportunity that you have coming into a really large enterprise as an interesting net new business. 

Really how we tried to think about it is Cisco having done well over 200 acquisitions can do that for you that being accelerated revenue growth but they also were very good about learning from acquisitions and they generally sort of have this approach to when they buy a company in addition to accelerating their revenue growth through a very large sales force and really the best partner sales organization in the world, they can also help learn what are the things that the acquired business does extremely well. 

And then helps scale them up and out to the other business units in the company. So when you look across Cisco there are many, many, many cloud offers. Not all of them are necessarily growing up with the type of security background that we have and what I have been really thrilled with is A, I think there has been a great effort to make sure that other parts of the company understand what we do well. We have been able to collaboratively export some of our way of thinking. 

Some of the tooling and technologies that we had, we exchange people and ideas with other businesses but also with the major corporate functions in the company and that has been encouraging even just to what is probably a relatively short period of time of you know, 15, 16 months now we have seen a lot of really good business results. You can think about the cloud security posture or strategy as a heavy anthem Duo green in it throughout and representation from many of the other large cloud business too. 

Which is very, very encouraging to us. I would also say it is good for Cisco’s customers because in a very large enterprise context like this when I have peers like Brocky and App Dynamics, which are also very large cloud businesses or open DMS, which now goes by the name of Umbrella, that is a huge advantage for us to be able to openly share under the tent of Cisco information about what our challenges are, the things that we do well and the thing that we need help with. 

And you build up this sort of interesting immunity that comes from having that free flow of information across a very diverse set of cloud businesses but all working with the same company on the front of your badge. So I spent actually a great deal of time every week with my peers who run security for those other business units within Cisco and that’s been very, very fruitful for us as well from a defensive standpoint. 

[0:28:34.4] Guy Podjarny: Cool, so each of these groups can still sort of autonomously manage and then supported by knowledge sharing and tool sharing and the likes between the groups as opposed to you know, whatever sort of elevating and having some element to top down mandate, which is like a collaborative in this fashion or the other. 

[0:28:50.9] Michael Hanley: Yeah that’s right, which has been very encouraging because if you look at just the businesses that I mentioned, Umbrella, Duo, Brocky and AppDynamics, these are all very diverse businesses with different sets of objectives, different state, which is growth life cycle, very different technology stacks but I think I would potentially speak for my peers here and those other businesses by saying we all get a tremendous amount of value out of sharing openly and transparently with each other across all those dimensions that I mentioned. 

[0:29:18.9] Guy Podjarny: Cool, you did a lot with this in the cloud app say like cloud security or secure your applications when they are cloud operated and hosted and you know a good portion of Cisco is in term of views moving into it. What would you say like in these learnings or to sound the highlights of the differences and how you should operate your kind of app sec or your security practice if you were to say move to the cloud, right? If you were to open up a new manage service and in an environment where you have a handle on the non-cloud surroundings. 

[0:29:50.2] Michael Hanley: Yeah, good question. I think for businesses or products that are making a transition from on-premise to the cloud or on premise but with cloud management, there is probably a natural tendency to maybe just like pick things up and put them in the cloud and then figure the rest out later but as I am sure you would agree the cloud security space has evolved very rapidly especially in your last – I mean gosh, I think in the last two years. 

I feel like there’s been a tremendous amount of changes and complexity is the enemy of success in a lot of these cases and unfortunately, a lot of the infrastructure and platform options that are out there can be very difficult to approach if you don’t have prior experience building and operating on that. So searching for ways to provide operational safety and easy security properties for your developers to get as you under trade the transition like that ends up being a really important strategic goal. 

That is important from the outside because I mean look no further than some of the top cloud breaches that we have seen in the last several years. You know misconfigured as three buckets, open IM permissions, you name it. Many of these just simply comes from the fact that these are complex and difficult to figure properly services. So to the extent that you can place the right guardrails in place to assure success for your engineers who are going through that difficult transition sends a main as a really critical primitive that I think has to be motivating your security team throughout that process. 

[0:31:11.2] Guy Podjarny: Yeah, definitely. It is those shifts and lifts there it is not that simple. You know you have to work to maintain the simplicity. A lot of it is about the security hygiene at scale, right? Just being able to reign in the beast otherwise it would get away from you. So I don’t know, I have a pile of more questions. 

[0:31:29.6] Michael Hanley: Yeah, I can keep going. I am doing good on time if you want to keep going. 

[0:31:31.5] Guy Podjarny: I’ll do one more and then I will ask you with that sort of pet peeve. So you’ve got a really interesting perspective here Mike between on one had you got your forward thinking approach of security inside Duo and then you got the collaboration with the other groups within Cisco but then you also have the approach with the customers. 

How much do you and your team engage sort of Duo the security product when you are trying to make a sale beyond just talking about why Duo itself is secure but rather around the substance of what Duo offers and does that change anything to like who you hire or how you work? Is it good, bad? 

[0:32:08.5] Michael Hanley: Yeah that is another great question. The answer is extensively to all those dynamics of it. I am a big believer that in addition to making it easy for our engineering and product teams to deliver excellent secure software, we also have a responsibility to be trusted advisers to our customers. So to that end where we see opportunities to assists our customers or if it is in the sales cycle, if I can bring to bear the folks who operate our own Duo deployment or who have influenced the strategy with which we deployed Duo inside Cisco. 

To share knowledge and experience, best practices, ways of thinking about using our product with our customers, that is going to help them maximize the value that they get out of coming to us as a service provider. We know they have a lot of options and it is not just paying a monthly subscription for that. It is their day to day customer experience with working with us and we have an important set of responsibilities in that. 

I’d say the second piece is we also get a lot of value out of those engagements because I generally find a lot of us security team to security team conversations, I can get really candid feedback from my peers about what’s not working, what do they want to see and that’s a perspective that I can share back with our product team in a way that I think is a little bit unique just because in general I can understand where some of those things are coming from in a different way especially when I am talking to a peer security leader. 

Yeah, exactly. We’re also customer zero. So I sort of eluded to this a moment ago but we protect all of our own infrastructure with the beta version of our product. So that is important for two reasons. One I would rather find and fix an issue internally first before it gets to our customers. Two is we want to be the most sophisticated user to our own product to make sure that feedback about what we like, what we don’t like, what’s working for us feeds directly back into our product team. 

So very important on that front. The second piece is, you know many of the folks in our team also came from organizations that are customers of Duo. So we had a lot of folks who had led security, various customer organizations who had come in to work with us and each one of them brings with them really important customer empathy and customer adaptations and customer experience that shapes our larger security strategy and helps us think about how to best engage with our own constituents. 

[0:34:18.6] Guy Podjarny: Yeah that is awesome. I think that’s definitely a unique proposition that I like. We talk about this, it’s nick was talked about in developers and the security side, you build developer tools, some developers have opinions. You have to be careful to not over rotate this towards your opinions because you are not always the profile but you know, still to have opinions and empathy that security people have some sort of empathy. I guess you want to maximize the value to get on those. 

[0:34:41.6] Michael Hanley: Yeah exactly and a good way to think about this in terms of just like abstracting it to we’re generally accessible concept is I don’t necessarily expect the security team to all act as product managers nor would I expect our engineers to all become security engineers but what I do want them to understand is you know some of the primitives of good product management like what are the things that will make it easier for our clients, engineering in this case. 

Easier to get their job done and how do we prioritize and actually deliver solutions that are easy for them to use. So many of the same primitives that you’d see in delivering our product. If it is requirements documentation or user stories, function requires, document, agile sprints to actually go build and deliver the stuff. We run our security team very much in the same way any engineering team would run because that’s the model on which we wanted to deliver to our customers. 

[0:35:24.7] Guy Podjarny: Well that’s awesome. So I think there is a ton of great insights. Thanks a lot for sharing all of that and before I let you get back to running data and secure the empire, can I ask you, I like to ask every guest, if you have one piece of advice or one bit of emphasis for some security practice that you give a team looking to level up their security what would that be? 

[0:35:46.9] Michael Hanley: The most important piece of advice I would give is seek diversity of experiences, diversity of thought, diversity of opinion on security, because the reality is our space as we sort of touched on a few times during this conversation is moving so quickly at any given time that it is really, really dangerous for your security team to get trapped and what’s always worked or what worked last time and you have to constantly be challenging yourself. 

I think when you are hiring in terms of looking for people who will bring new contribution and ways of thinking to your team. If you just hired for fit you are going to miss those opportunities. What you want to look for is actually a contribution to your way of thinking. So really I would challenge teams to not just go look for what worked in their last gig or what worked on their last hire and really think deeply about what’s going to help them get to the best possible business outcome. 

And on that second point, really focusing on business outcomes because security teams are at the end of the day trying to help increase the level of assurance and confidence and de-risk the businesses’ delivery to customers and internal clients and if you lose sight of that, if you don’t understand what the business is trying to accomplish again, that’s a care where your credibility as a team can go downhill very, very quickly and it is very hard to recover from that.

[0:36:59.5] Guy Podjarny: Yeah, well awesome piece of advice. So if people want to join your team, you know I assume you’re hiring, where should they go search? 

[0:37:05.6] Michael Hanley: Yep, we’re hiring, plenty of roles open across Duo and we are continuing to grow inside Cisco. You could go to duo.com/jobs if you are interested in looking at some of those open positions. 

[0:37:15.2] Guy Podjarny: Perfect. Well Mike, this has been a pleasure having you on board. Thanks for joining us.

[0:37:20.0] Michael Hanley: Thanks Guy, it’s been a pleasure to be here. I appreciate it. 

[0:37:22.4] Guy Podjarny: And thanks everybody for tuning in and I hope you join us for the next one. 

[END OF INTERVIEW]