How To Embrace The Organizational Revolution As A Next Generation Security Leader With Roland Cloutier

[INTERVIEW] 

[0:01:26.2] Guy Podjarny: Hello, everybody. Thanks for tuning back in. We today have a person whose security responsibility is quite broad in an organization, very much a top-tier enterprise. We have Roland Cloutier from ADP, who is the Chief Security Officer at ADP. Welcome to the show, Roland. Thanks for coming on. 

[0:01:41.5] Roland Cloutier: Yeah, great to be here. Thanks for having me. 

[0:01:43.6] Guy Podjarny: Roland, we have a whole bunch of things to talk about today. I think we'll tap hopefully into both your general forward-thinking, but also your experience in large enterprise and not just the theories of modern security and developers and all that, but dealing with it in the trenches and actually executing it in a large organization. Before we dig into those, can you tell us a little bit about yourself? What is it that you do today, but also how did you get into security? What has been your journey? 

[0:02:08.9] Roland Cloutier: Yeah. Interesting enough, I actually came from the law enforcement and military side; started out in the Air Force, believe it or not, as a combat security policeman my focus was on aerospace defense. One day, I left the Air Force and Department of Defense, nine countries and six years, it was time for me to head home and I got into federal law enforcement. 

Soon, what I found is that every crime has something to do with a computer. Everything we're invested in. Which is crazy, right? I kept going to some friends of mine who were in computer science and they said, “Maybe you should just go back to school for this and stop bugging us,” in a polite way. I did that. I went back to BU for a couple years. Came out and just got bit by the bug, man. I loved the whole idea of defending and understanding the deep aspects of the technology and eventually owned a couple of my own companies after I had worked for companies like EDS and got sucked into the dark commercial world and ended up becoming the first CISO at EMC. 

[0:03:14.4] Guy Podjarny: With those first companies, were you doing a security role, or were you running the business? 

[0:03:20.5] Roland Cloutier: It was more consulting. It was security, so when I stepped into EDS, it was actually building security teams for critical infrastructure defense, which was fun. I mean, every day something's breaking, you're building it. In the late 90s, early 2000s, when there were not a lot of security practitioners, you didn't have formal critical and instant response centers. It was a handful of men and women that were saying, “Hey, you're the security team. Help us figure out how to protect this network,” and before all the great technology that we have today was even out. Yeah, I was doing all the ground-pounding stuff. 

[0:03:57.8] Guy Podjarny: Got it. Okay, sorry and I cut you off. You did that consulting and then you got into being the CISO. 

[0:04:02.7] Roland Cloutier: Yeah, at EMC. That was great. Started there with, we like to say nine guys and a firewall or two, ended up building a global security, converged security organization with over 200 folks; some of the best practitioners I had ever worked with. Spent several years there and then got sucked down towards the city and next Tuesday makes a decade I've been with ADP now. 10 years. It's been absolutely amazing. A different job every day. Quite frankly, I feel like I've only been here a couple of years. It's crazy. 

[0:04:35.6] Guy Podjarny: Yeah. Well, they must be doing something right to have you to stick around for a decade. That’s some scary work. Let's start unraveling a little bit the security organization. What does your security org look like and what are the primary teams? We'll get into dev right after. 

[0:04:51.1] Roland Cloutier: Yeah. Guy, like we had spoken before, I have converged security organizations. That means that there's one throat to choke, or back to pat, I guess however you want to look at it from a corporate perspective. All security functions and operational risk functions roll up into something called the Global Security Organization. That's what I'm fortunate enough to lead. We have traditional cyber defensive operation. Think about cyber engineering, operations, app dev, security testing and analysis, global vulnerability assurance, those core teams within our technical security services stack. 

Then we followed the critical infrastructure and banking model. We have a threat and incident management group. This is our four critical incident response centers around the globe. We are a human capital management and as part of that, we have a lot of information, information on money. Data moves all over the place. We have a specifically built team for business security incidents. These are non-cyber incidents, if you will, but things that are more data or privacy that we want to be able to respond quickly too. 

Then of course, our core threat intel and red teams, that stack. Then we have a – we call it converged security. A lot of people call it corporate security. Criminal and civil investigations, Office of Public Safety for our campuses, associate protection teams to make sure our associates are safe wherever they are all around the globe. You can consider that our police department, if you will. We have about 60,000 associates operating in about 80 different countries. It's a midsize city. Of course, with that comes a lot of responsibility to ensure our people are protected and our sites are as well. 

They also manage our global business resilience and crisis response team. At ADP, our business resiliency is composed of business continuity, disaster recovery and crisis management. Disaster recovery from an operational standpoint actually sits within our global products and technology, or our IT organization and our facilities organizations, if you will. Business impact analysis, business continuity planning and when really things go bad, the crisis management itself falls within an organization that I support globally. We have one centralized organization to do that. 

Then we have our own financial crimes stack. Obviously, ADP – one of six people in your street lose/moves(?) a few trillion dollars a year. We have a team of dedicated practitioners that just focus on anti-fraud, fraud defense, fraud investigations, and putting bad people in jail around the globe. Then we have our office of trust. This is a team that deals with our clients, about 750,000 clients around the globe. They all want to know how we protect their information, what our security program is like. 

Then we have a lot of partners and our own internal associates that we want to train, educate, and ensure that they understand their responsibility. They do end-user awareness training, client engagements. Finally, they work actually with our field, our sales, and our client-facing folks, to create content and have those discussions with the client as well. We spend a lot of time there. 

Then the really final piece to that puzzle is all of the folks that we have that sit in the business. We have our business security office that has business security analysts, technical security managers. They serve three functions. One is to make sure that all the businesses we have are getting the centralized security services that they need. The second is to make sure the centralized security services know what the business really needs to build it in to our systems, into our processes, into our services. The last component is really to ride shotgun. I mean, these men and women do an amazing job of educating the business on the why, the what, and helping them prioritize on reducing risk within their business. 

A lot of times, we don't even call it “security” here at ADP. It’s business operations protection. It's really about, how do we protect that business? Then our two supporting functions underneath that is our converged security architecture. Instead of each stack having their own architects, we have one set of architects that work for all of those programs, both product and defensive operations, so we can leverage resources, technology platforms, instead of building them independently for everything. 

Then, if you were to think about the size of my operation, I'm about big enough to go public. I mean, if I was a managed security services firm, we're probably that large. I have a business operations function that does portfolio management, finance, and all of those things underneath it. In three minutes or less, I guess that's the entirety of our program. 

[0:09:41.3] Guy Podjarny: Well, that's quite an empire there, right? There's a lot of different moving pieces. We’ll naturally dig a bit more into some of that app dev and how you engage, but let’s keep it still just a little bit at a higher level. I have a couple of question that came out. One is, you mentioned these, the business security officers. Do they interact all the way down to the need of that app dev? I’m trying to understand the matrix here when it comes to product development and the likes, versus the per business security perspective. Are those two very independent things? Do business security people have some responsibility for the app dev within their businesses? How does that work? 

[0:10:16.6] Roland Cloutier: Yeah. They have some responsibility in the product, but not at the app dev. We have a global group of architects. What we do is we take a senior security architect and we put them in the product. Instead of delivering independent services and pontificating from on high and “thou shall” and “I'll review your stuff,” we put them in with the DevOps groups. 

Their focus is to sit there at the time of design, thought leadership and development to actually be the expert on the teams. That is where core defensive development gets introduced into the products. We call it ‘by design’. We have security by design and privacy by design. 

The BSO, so you bring up a good point. The business security officers have an important function. They take the information we have out of our global vulnerability management, or security testing and analysis teams. They ensure that – and I'll use a loose term, we score our products. You have to maintain a certain level of scoring, if you will, to be able to go GA with your product. 

They help the business understand that and make the appropriate changes to the products when things come up. We don't want to slow down the DevSecOps teams, or the DevOps groups with vulnerability issues that can be just put back into rally and run at full speed and triaging going forward, but we want the business to understand their problems and their products and we let the business security teams handle those. 

[0:11:54.1] Guy Podjarny: Got it. For the first part and those security architects, they're basically embedded within the DevOps teams. They report up into a central architecture team. Are they perpetually embedded, or is it per project? Is it a person that would come in and out of those teams, or is there a person that they know – 

[0:12:10.4] Roland Cloutier: No, we want a historical knowledge of the previous product, so we want them embedded. We want them to understand the go-to-market, what that product is going to do, and how it's going to develop over the next three years. Yeah. They're really part of the team. 

[0:12:21.5] Guy Podjarny: Got it. Okay. That makes perfect sense. One more question, high-level, is how have you seen that – like you've been there – you've run this group for 10 years. I'd imagine that ADP, like most enterprises have certainly invested more in digital and modernizing and maybe embracing the cloud. What would you say are the major changes that have occurred into this format between 10 years ago and today, into how do you build the org? 

[0:12:48.9] Roland Cloutier: I'll be real straight here. This is really only two-years-old, maybe three-years-old, we started to talk about ‘by design’. Because what happens in every enterprise? You have really smart technologists that are looking at next gen technology and running fast and then you have a legacy security entity that has a phases and gates process and a waterfall to be able to integrate. All of a sudden, you're so far behind. 

We knew, because we listened to the market, we talked to other experts. We knew we did not want to be in a place where we were slowing down the go-to market that would generate the revenue that was on the plan. We said, “Let's take a different step. We'll take a chapter out of a couple other people's books.” We went to Salesforce. We sat down with teams at Google. We spoke to the folks at Amex that were on the same – We spoke to other professionals and we thought that this model worked well for us, and so we started down this journey. 

It took some getting used to. Quite frankly, we actually had to hire different types of people in place. A lot of our engineers today that are working on cloud, or working on open source defense, they managed firewalls at one point, or they wrote dev code for something else. We trained them into these positions, because we always keep a three-year, what are we going to meet next based on the commitments of the business? What we found in this space is we didn't have the right skillset at an architect level. Almost all of our architects are new to the business in the last two years. 

That was a big change for us, because we're a big believer in taking your skilled workforce, educating them on the needs of the business, and empowering them to change their careers to get there. Most people have a 21% turnover rate. I'll brag a little bit. We're always somewhere between 6% and 8%. The highest we've hit in the last five years is 12%. We monitor these things, because it's super important. It's really expensive to go find new talent. It takes a long time to get people up to date. 

If you can engage your talent pool, if you can make them successful, if you can give them different jobs in a career inside a single organization, we feel it's better for the company, it's better for them, and it's a win-win. That's what we've done. 

[0:15:15.5] Guy Podjarny: That makes perfect sense, both for the business as you grow those individuals, you’re less behind. You ensure that they have the right skills that you actually want them to have and then it's great for the individuals. They get to grow, they want to stick around clearly, because they can trust that ADP have their back, and actually help them adapt as the business changes. That's really insightful as one of the key changes is this ‘by design’ element and then you veered into the skills changes that are needed. 

There's an aspect of it which is you're trying to carry along the people and evolve their skills to this model. You've mentioned one specific skill, which is one of architecture that you felt you needed to bring in. What other primary skills did you need to level up, or rather skills that you felt were no longer as necessary amidst the team, regardless of whether you hired them from outside, or if you had to build them in, or to rope people into them? 

[0:16:13.3] Roland Cloutier: I'll hit two right off the bat. I mean, I'm assuming just everyone else, all of your listeners probably have the same challenges as well with developers. I mean, we're a protective-defensive shop. We had engineers, right? We had people that understand everything from NT 4.0 up to Linux kernels and everything in between on how to defend it. 

A lot of what we do now is develop into the product sets, or develop into the business process to be able to exchange the information necessary. For example, we collect 25 billion events a day on our platform. Think about it, our security intelligence platforms, it's a big elk stack. We're on one platform globally. That means we collect for all of our products that’s around the world and aggregate into regions and bring that back into a massive security intelligence data warehouse.  

Now how do you develop against that? That's not content development. That's data science. We've had to bring in folks that understand how to develop our platforms to be able to code, to exchange the information. We have to bring in data scientists that built out our data science piece, so we're not doing simple correlation. We're doing advanced analytics. We're doing some ML. AI didn't really work well for us in this sense. We've actually outsourced most of our AI stuff to some providers, but that core skill had to be developed. 

Then the output of that, you need an analyst. I mean, so we've actually had to hire some folks with that skill set. I mean, we've got some amazing practitioners we've brought in that had nothing to do with security prior but are incredible data analysts. Then you give them that strong security – those security underpinnings. You give them context to understand the what and why of cyber and they become just enthralled, like I did with stopping bad people and understanding what's happening and they've got that core skill set. We're just doing some amazing things. I mean, I can talk about all the skills, but if I had to name the top ones, really, it's app dev, data science, and analysts. 

[0:18:26.1] Guy Podjarny: Yeah. Well, both pretty much the skillset that the world as a whole – not that surprising – that the world as a whole is in growing demand of. Also, maybe there is a little bit of a positive spin to the fact that with security talent being in such shortage, once again if you're able to let build security knowledge into people to come with that type of other background and you're able to scale your team, it will be much better. 

[0:18:47.2] Roland Cloutier: Yeah. Yeah, I agree. 

[0:18:48.6] Guy Podjarny: Let's indeed double-click there. That's an old analogy. Go deeper into this world of app dev and the applications themselves. We talked about the organization but in practice, when you think about one of the more modern application teams out there that is deploying maybe cloud, that software within ADP, how does the security team engage over there in a regular course of operation? Which teams are involved? How is their daily interaction? You mentioned one embedded app, but you also mentioned app dev teams and the likes. How does that work? 

[0:19:26.0] Roland Cloutier: Yeah. Let's segment into two areas right now. Our next four advanced technology and our go-to-market, all four are built on native cloud. We've parsed out two really specific areas. Think of it as INO, or infrastructure and operations in cloud, and app dev. Folks building the products as set on top of that infrastructure. From an infrastructure standpoint, what we've done is we've created a model, or a what we call smart cloud, I know, really fancy names, but smart cloud and we're at 2.0 right now that they're building out, which is essentially an on-ramp and standardization capability for the clouds that we sit in. 

It's minimum level of controls, minimum level of technology management. For instance, in our DevSecOp model, we don't allow people to manage their firewalls. That is done by a centralized security INO function and with our partners in global technology. They don't make their own AMIs. There's a platform assurance group that creates the AMIs they need to be able to run. They don't manage the security output of their container. They just need the container. They don't need to manage the container management piece of it. We provide that service for them. 

We've broken out as basic INO functions as a service, almost if you were to go to AWS and say like, “I need this OS. I need this service and I need these three functions.” We give that to them in a managed fashion. Behind the scenes, we have what would have been, I think people would call, “legacy enterprise security people,” that are now providing these as cloud services, using different tool sets, but eventually using many processes internally to manage both to defend, to detect and to protect in the respond side of the house. 

On the app’s dev piece, we've introduced a whole new set of technology. We have standardized code repositories, rally infrastructure, bug management, and threat management. It's interesting, once you start planning for your code, we have a threat modeling as a service, so it automatically goes in, they lay out their plan and we do the threat modeling based on the type of product, the type of information and data they intend to touch if they're going to move money. All of that stuff comes out with the requirements, gets automatically put into the rally and then that is discussed amongst the dev team with the senior architect. 

The SecOps portion of that, or the DevSec portion of that, is done by the dev teams. We're building that skill set into developers. We're not having security people doing it for them. This is truly security by design and we're upskilling our developers to give them that capability to do it through tools and mentorship. 

If you give them the tools and they get the output and there's someone explaining it to them, they're going to do it the second time. That works super well. It lets us stay out of the way, so we're not having to do check validation independently. When they post their code back in at the end of the day, we've made an investment in automated code scanning. We're not waiting till compiled code, or pre-compiled code, to get there. We're doing at time of coding. 

By the time they come back in the morning, they get their bug list and they're back at it. This way, we can actually tell by teams and we can actually tell by product who's getting it and who isn't getting it. We can refocus the architects in those sections to say, “Hey, Jimmy or Sally's not really getting it. Can you spend more time with them? They had 30% of the bugs in that code, or for their group.” It's really through tooling, education and trial by fire a little bit. 

[0:23:32.0] Guy Podjarny: Both sound like really great programs. It sounds like on the app dev side there's a service element but is that embedding with that security architect and the by design drive. While on the INO side, it's a little bit more the guardrails, a little bit more driven by, “We're going to do this for you.” I guess there's a – how much have these acted as constraints? I mean, how much has the fact that you can’t pick any old container, but rather just the ones that have been approved, or any AMI. How much is that – 

[0:24:02.3] Roland Cloutier: Initially, it was painful, because people just wanted to run with scissors down the hall and didn't know that if I fell, I was going to have a bad day. A couple people fell and got stitches. Product issues, security issues, slowed them down. They started to see that. Guy, where we're still having issues and I'd be interested in your opinion on this, is all of the cool tools that are coming out – here's a code we haven't cracked – if a developer is in – just loves and we'll just use AWS. It's easiest and it's our biggest footprint. If a developer goes in and sees a new function, a new service, a new capability in AWS, and they're releasing every week now, they’re releasing every month, now they're releasing every week. 

It's not pre-certified. It hasn't been validated. At the end of the day, it's essentially, we whitelist the tools they can use, so it's not available. That's still causing a problem. We feel we're constraining them, because we can't do this fast enough. We're not sure how to, because a lot have said to enable access to data elements on the backend, how does that bypass existing controls? Can we take data elements out of that to bring back in from monitoring and management? We have to do that work. That's not 10 minutes. And there's a stack of requests. I'm interested in what your thoughts are around that, because this has been tough. 

[0:25:25.0] Guy Podjarny: Indeed. Yeah. Well, and I've got plenty. I think the two primary examples of how to tackle this, or points that I would raise are, one is what's called the paved path, or the paved road approach. It's basically splitting up the things that are in the paved path. This is the easiest. Just choose one of these and you're going and it's going to be the easiest, most frictionless experience. 

On the other side, you've got the hard gates. Some of these constraints are just non-negotiable and it's sad that they slow something down, but it's reality. You just have to stay within these boundaries. There are gaps, there's off-road between those fences and the paved path. If you go off-road, then you need to do more work. You basically roll some constraints, or some diligence that you require those development teams to do if they want to choose those. They're not – 

[0:26:13.8] Roland Cloutier: You make them do the work on your behalf, if you will, and provide the results back prior to going forward? 

[0:26:20.5] Guy Podjarny: Precisely. That serves a dual purpose. One is of course, you allow them autonomy, but you say, “Well, if you want this power, you get this responsibility as well.” You have to maybe fill in some models and some questionnaires and be able to answer these. Some of that work is done. By the time three teams have done that and by the time it gets to you, the central security team, it might be in slightly better shape, right? It might save you some cycles to those developers that probably still – as big as your security organization is – I suspect it's still outnumbered by the number of developers by a good ratio. 

Then the other thing that it does is that it actually raises awareness within these development teams, because it makes them appreciate the questions in place. You would need to invest in making this process educational and not just bureaucratic to say you have to do those processes. I think that's probably the best path. Quite a few guests on the show have named that paved path approach is one they like, and I think it's a good one. 

The other point I would say, and I would actually be curious to see if you've encountered this as a shift, is you mentioned AMIs and containers. I would posit that there's a trend that is basically in the world of cloud moving IT into app and moving from IT people, or INO people into dev. A good example of that might be the VMs, or the AMI versus the container. 

The AMI, technically the same. It's a base image of which you build for your software, similar conceptually and some technical differences, of course, the engine that runs them. Operationally, your Docker file sits on a repository, patching it requires a rebuild that typically includes more than just building the image. It also includes picking up pieces from the app itself and it's much more of a dev practice. We see some of that trend going with network with the VPC configuration versus a service mesh. 

You might see it in a MongoDB that's built into your application versus an OracleDB that you managed off to the side. How much have you observed? Is that trend of maybe INO to app dev, or relations – 

[0:28:23.6] Roland Cloutier: Absolutely. Way down the road. Yeah. Our partners over in global products and technology, actually, at the same time that we were embracing DevSecOps said, “We need to get to DevOps, but more importantly, we need to get to standardization around some of the technologies they were using.” I mean, understand that it’s a four thousand person development and technology organization. It's 12 different divisions and I don't know how many hundreds of products at this point. It's a big world. That's absolutely where they're going.  

But making sure that there's accountable people, humans that have that specific job, to make sure that the right AMIs are available, that they're constantly kept up-to-date, they're part of the dev teams now. They’re moving to be part of the dev teams. What we've made a conscious effort at is not losing the rigor around functional accountability, because where we have seen other companies fail miserably is when they say, “Yeah, yeah, yeah. We're going to move those over to the dev teams.” All of a sudden, no one wants to do that work. 

[0:29:33.8] Guy Podjarny: They don’t want it done. 

[0:29:35.1] Roland Cloutier: Yeah. They don't get it done. There's no operational maintenance. There's no guardrails. I think our partners over on GPT, or Global Products and Technology started with that in mind with we're not going to fail, and so we're going to do this at a reasonable rate. That's absolutely the practice that they're migrating to. 

SDN integrated at the product level, with guardrails that folks in DevOps going per product are required to manage. “IT” is not going to come up and start spinning up and spinning down instances to make sure that you've refreshed the latest AMI. They're going to provide you with certain things and that’s the devs group’s responsibility to go get that done. 

[0:30:15.4] Guy Podjarny: Yeah. Yeah. Makes perfect sense. Of course, yeah, this is going to evolve. Not all parts of the organization are going to move in the same units. Let's indeed talk a little bit about the change. This is an organizational revolution. We talked about how the security org had to adapt. What changes did you need to instill amidst the dev team side? What practices did you have to instill? What was easy? What was hard? 

[0:30:38.9] Roland Cloutier: Let’s start on the security organization side. I think that's where some of the bigger changes had to happen in the mind shift. First and foremost, we had to get into a cycle of where we changed how we were doing our own development work. How we were actually managing our service and developing our services and delivering them and we had to really change and embrace new styles of work. I think that was number one. We had to bring people together and teach them new ways to work. 

The second is, we had a move from straight service delivery to threat-led defense. Submission segments, right? We started getting way too siloed, if you will. We're technical security services. We do these five functions. We’re threat and center management. We do these threats. That's not who we are, but that some organizations that just sometimes that's what happened. What we said is you know what? We have cyber, we have data defense, we have public safety, we have financial crimes, those are mission segments. 

I need an architect. I need an engineer. It should start with risk. I need all of these things to be part of that mission segment. We created executive owners of the missions and key directors responsible for the mission segments and then populated each one of those. It drove transparency and understanding of what we were trying to accomplish in each one of those areas. That was a big change and it got people focused on how to work faster in a specific mission segment without throwing stuff over the fence on a constant basis. 

[0:32:20.7] Guy Podjarny: Yeah. How long did it take to overhaul? I'm sure there's a lot of planning once enacted, once designed, was this a hard switch?

[0:32:30.0] Roland Cloutier: Oh, no. We’re still doing it. We're 18 months into it and we're still doing it, Guy. I mean, it's probably a two-year evolution to get it to a CMM level 4 type thing, but it's a couple-year conversion, because you're moving people from a service-based delivery model to a missions-based defense model and it's just different, but it works. 

The next step was – listen, we're not going to go into the dev world and tell them what to do, or just automatically attach them. We had the architects in there. We started our ‘by design’ process. What we really, really felt and I think what made us successful, especially in the three first iterations of this, was to give them the tools. We didn't say, “We're going to introduce you to our technology.” Our security from the time that we do threat analysis of their design, to the time that we’re supporting them on bug code management right through each aspect of the rally, it's their tools. We coded into their tools. 

Then what we did is we took the other – our code monitoring, our security testing analysis tools, all of those things, and we automated it into their platform, what they develop on, and we gave them a, “Here, use this tool set,” type of service. They want to test it themselves, go ahead. We expanded our licensing to allow them to essentially check in and check out tools to use against their code. Embedding that into how they work was a big component of it. Change how we work operationally, and give the tools away into their tooling, was I think brilliant on the team’s part to get us where we are today. 

[0:34:15.4] Guy Podjarny: Yeah. It sounds super critical. Has that impacted your choice of tools? Was there a set of tools that you had to reconfigure because they fit the bill from a functional perspective when they were operated by a security expert, but they didn't – they weren't fit for purpose when you thought about dev teams running them? 

[0:34:36.1] Roland Cloutier: We had tools that weren't working, that we had to get rid of, different suites of tools, because they wouldn't integrate natively via API into the coding infrastructure. Since then though, we've worked with companies – I don't want to mention specific companies – we've worked with them, because their tools are so good to get them to do that and we brought them back in. 

Again, it's ‘by design’. We have some basic principles. It has to be automated. It has to be integrated into the developer’s toolset, not us forcing tools down their throat that they're never going to use. There has to be a self-service capability. Those tools have to integrate back. Meaning, they have to be capable of exfiltrating their information. 

For instance, if a post-compile assessment done is with a certain tool set, that information will actually not just go into their bug tracking but will be exported to our GRC platform for that product, which will automatically update their product score. I mean, it's that automatic. What we didn't want to do is add on more text field data, put it into a data hub, parse it back out, make it someone's job to do that. The basic reliance here is on automation. 

[0:35:45.7] Guy Podjarny: Yeah. You need to scale the operation of the tool, but you also need to scale the governance of these activities coming in at the same time. Did you find the incentive model for development had to be touched? I mean, there's been a lot of conversation on the show on celebrating security successes, anywhere from stickers to hoodies, to all sorts of holiday retreats when – 

[0:36:08.8] Roland Cloutier: Well, we haven't gotten that far yet with the retreats. 

[0:36:11.7] Guy Podjarny: How do you do that? How do you celebrate security successes for people that are not in the security org? 

[0:36:16.7] Roland Cloutier: Yeah. We have a safe program. We have we have two programs. One, we have a CSO award. The CSO award can only be awarded to someone outside of the security organization. What's great is that they can really be – it can be initiated by anyone, but we prefer it be initiated by a security practitioner recognizing somebody within development or inside the business. 

I mentioned the safe program. This is where people sign up, because they want to learn more about security. We follow kind of like the Salesforce model where you have different belts, right? You have white belt, yellow belt, green belt, blue belt, black belt. In there, you get different awards based on your skill set, how you're participating, things you find, and how you score out some of the things.  

I don't want to call them games, but it's gamification of education, if you will. A black belt, I sit down with our black belts and we have conversations about security. They get access to some of our intelligence programs that we just don't allow everyone in the company to have access to. They get special access. They get a special focus. They get special awards, as they're part of this. 

Now, I'm going to bring up the negative side of it though, because I think it's important. We always focus on good behavior, but there are some people; good, better, and different that I've just found throughout my career that they just don't give a crap. They don't want to do it. That's not the way they've done it. They're not going to do it. They do things counter to the strategic direction of the development organization, of the company. 

Those people that don't get it, that aren't going to put the client first in the security insurance of their information, or their data through good quality coding, this isn't secure coding. This is just good quality code. If they're not going to take that seriously, they don't need to be with the business. 

I think our CIO, our SVP of products, and our president of global products and technology take that really seriously. They look at the conduct part of it. They do all the right things of education and providing internal training and things like that. Those people that don't reach that level, you're not going to be a C+ player on the ADP team coding the future of our business. They make that known as well, I think which incentivizes other people to be the best they can be. 

[0:38:44.3] Guy Podjarny: Yeah. No, absolutely. I mean, it has to also celebrate those who do it well, but you also have to keep your organization at a certain caliber. We're already going to go long, but I have two questions I still need to get in here. One is, how do you measure all this stuff? You have a lot of moving parts. You want to do a lot of things right. How do you measure security as a whole and maybe if there's a specific angle about this transition, this change, and in the new model, how do you know if it works or not? 

[0:39:15.8] Roland Cloutier: Every program, project, mission area service has a KRI KPI. I wish I could actually throw it on the screen. We have an amazing platform that we call Althena, where we collect information out of our tool sets, out of our GRC, out of our data hub, and we do automated analysis. It is the same platform that I use to deliver metrics and measures to the board of directors, the audit committee, the executive committee, the executive security council, and oversight organizations, same exact information. 

We look at our service areas through these KRIs and these KPIs. I think the important part is we make that information available to different parts of the business. If you're a GM of a certain product set, you get information, you get access to that information about the platform you're sitting in, about the technology you're on, so on and so forth. 

The development teams get access to their scorecards. We have security scorecards for each product. It rates infrastructure, code, a bunch of things that we measure, like the effectiveness of the controls based on our red teaming and our global vulnerability assessment group. All of those things get measured. They can see themselves against their peers. Then because it's a single platform, they can actually go deep and get to the actual incidents and issues to be able to remediate those. 

The D in ADP, super important. We are a data intelligence-driven organization and we provide that back. We look at the efficacy of the tool, or control we're using, based on those scores. What’s cool though and you didn't ask is what we're doing in the coming year, because we actually brought in a firm to be able to go deep into the cost analysis in two areas. One is, what does this stuff really cost us off the GL? What does that defensive architecture cost? How much are we putting into it and how effective is it? 

So, we're a fair shop from a risk perspective, and so everything goes into our GRC. Today, we use fair maybe on 20% of our risk analysis, because it's a pretty heavy process, but we're working with a couple companies to actually do automated fair assessments bi-directionally out of our GRC out to their ML process and come back in.  

We'll have definitive fair risk alignment to the cost, back to the efficacy, the control that we already have. It's a pretty cool model that we're building to. Again, it all starts with understanding what controls what their efficacies are and how do you get that information to other people. 

[0:41:59.8] Guy Podjarny: The model sounds great and also aggregates at scale. I want to drill into the word efficacy. Oftentimes in security, measuring efficacy is a little tricky. Most typically, I've seen two paths. One that is more metric-driven about activity, if you will. Have I found vulnerabilities? Have I blocked attacks? A little bit more attributed to the functionality over this fold, as it does what it is supposed to be doing from a tactical, technical perspective.  

The other is more maybe risk assessment, of more trying to gauge, have I seen attacks go deeper, have I – more about those types of results - have red teams broken? Do they resonate? How do you assess efficacy for something as elusive as risk? 

[0:42:49.8] Roland Cloutier: Yeah. It's more of a mix. I would say it's more the former than the latter, because we actually have – is a tool needed? Do we still have the technology? Are we seeing an attack specific to what that control function is like? But we say, “Have we tested it?” We have a red team. We have a global vulnerability team. We have an intel team that provides the input specific to the control. By the way, we have a controls assurance group. We have that on purpose, because first, I do not look good in orange or stripes. 

Their job is to keep me out of jail and know that the controls that we have committed to, work. That's it. That's really their focus. They look at the control and do that. I don't think it'd be fair to say we have a perfect automated risk formula for the controls. We have risk formula via effective analysis. For information, risk we use generally across all of our controls and risks. I don't think it has an efficacy mark. 

I guess to my earlier point, this is where we want to go. We want to know the cost. We want to know the risk and we want to know the effectiveness and efficacy of that control to be able to create a better model. Yeah, that's the state of direction, the invested direction and where we're heading. 

[0:44:09.6] Guy Podjarny: Sounds farther ahead than most organizations that are in this state. With that in mind, I'll ask you one last question. It'll be a slight deviation from how I usually ask the end of questions, just because of having – it seems like you're still in the middle, but having done this transition from the more legacy, or so the previous view on how to do security, to a more modern view.  

If you have one key tip to give to a fellow CISO who has been in your shoes four years ago and is looking to try and shift to more where you are today, what's a primary piece of guidance that you would tell them? 

[0:44:48.2] Roland Cloutier: Yeah, it's simple. Get help. I mean, if you're not coming from a development world and you've been protecting things your entire life and you've grown up in a very different model, don't think you're going to read a couple of blogs and watch a video and a couple TED Talks and all of a sudden know how to do it, osmosis through a book. 

Find people who have done it. Find an outside organization, or a consultant, or someone and validate they've done it, but bring them in for their expertise. I think that's the number one thing that I can say. Find people that can make it happen for you. 

[0:45:22.7] Guy Podjarny: That's excellent advice. Very concise. If people want to join this security experience at ADP, where can they find job listings and the likes? 

[0:45:31.3] Roland Cloutier: Yeah. ADP.com. Just hit the jobs button, search global security, and we're always looking for incredible men and women that are mission-centric, want to be in the fight every day and that just loves doing what we do. Always something out there, so please go look. 

[0:45:44.6] Guy Podjarny: Excellent. Well Roland, this has been a pleasure. We’re already on one of the longer episodes, but I probably could have gone on with a whole bunch more questions. Thanks a lot for coming on the show. 

[0:45:55.6] Roland Cloutier: Guy, I appreciate it and hope to do it again with you. 

[0:45:58.9] Guy Podjarny: Thanks everybody for tuning back in. I hope you join us for the next one. 

[END OF INTERVIEW]