Event Recording
Darran Rolls: The Confessions of an X-CISO: Identity Centric Security @ Enterprise Scale
Glad to be here with everybody today. I know you can hear me well, cuz the great folks have already checked me out for, for sound. So we are, we are good to go by way of introduction. If you don't know me, I've been kicking around the identity management space now for 25 or more years, as sad as that is, I've done my time at way set sun Microsystems in Tivoli. And I was the CTO at sale point for 12 years for the last five years of that time at SalePoint, I was the C S O but at the beginning of this year, I retired from SalePoint. Great time there. Hence the X C I S O as I said, I'd explain that a little bit. And I'm now an advisor working with investors and clients to, you know, help with the next generation of IAM systems.
And in September, I was thrilled to join my long term friends here at coing Cole as a research fellow. Now, as I look back, I guess in the mirror as my time as a vendor and more relevantly today as, as the C S O of the public company, I just have to say, you know, wow, basically just an extremely tough job. The role of the C I S O is increasingly a challenging proposition for anyone. And like everyone that sits in an executive seat, you are continually balancing between business drivers, technology change and managed risk. And after speaking with lots of my peers and, and fellow CISOs over the years, I'm not sure that the scales are, are properly calibrate here, cuz when it comes to something like budget security, it's, it's always a cost center, right? How can it not be? And security risk is just so nefarious and so hard to communicate.
It's just a hard driver for a budget conversation. And if you bring that together with no actuary science here or metrics to balance the security, we might say premium against it. It's, it's just tough. And, and even if you could, who, who would you compare yourself to? Right? It, it can't be an internal department, you know, that's not right, cuz they're, they're the customer and it can't be other businesses either. Cuz we still really don't have a way of sharing program drivers and budget a across that boundary. So the CS O really is on his or her own. And you have to ask the question is the board really listening anyway, far too many organizations that I see, they hide the C I S O under it or operations. And you might say the business of security, it, it barely makes appendix K as they say in the board deck.
And it's just a sad, true still that most boards only really wake up to security when, when something bad happens and you know, the DPO or the news is, is, is, is, is pulling us in. So I really am glad to say that I'm an X, C I S O because things certainly aren't getting any easier here with the challenges that are being called that we cause that we're talking about in this conference around working from home and cloud and SAS, you know, and at a drive for zero trust security. I just say, thank goodness, there are events like this, that where we can come together, have a conversation and, and make, try and make sense of it all. Cause of course technology change is inevitable. No one would deny that, but you know, just when we thought we had a handle on client server and web, everything's changing again and the new world of DevOps and composite apps and microservices, it's a ground up rewrite for just about everybody.
And so to mind the, if you like the icing on the cake here really is the fact that the old stuff never goes away, right? We should just stop calling it legacy and embrace it as our runtime heritage. So a tough job being a CIS though, for sure. And that frustration is starting to show stress. Oh yeah. Plenty of that. In fact, really interesting survey by nominee earlier this year, they interviewed 800 CSOs from the us and the UK and they found that 48% of them said that work stress was having a detrimental impact on their mental health. And that stress probably accounts for the atrocious tenure numbers though in the industry today, several reports this year have pointed to the average tenure of a C IO now trending towards 20 months or less. And, and that's just a crazy short time for anybody to be in such a, you know, business critical role, but this isn't a psych conference.
So why have I chosen to open on this thing? And the answer is simple and that's, you can help if you are responsible for security and identity, I've got some program and technology architecture thoughts that can really help the C I S O stay same, a few recommendations on driving an identity centric approach to identity, identity security, to enterprise security that I hope can lower cost reduce complexity and improve overall security posture. So I think I've got about 15 minutes left, so let's jump into three helping hands you might say. And the first is expanding on one of the major themes of this event and that's building an integrated identity aware ecosystem and doing so with lower cost and less complexity. The second is around putting identity at the center of security operations and treating it as security, you know, rather than just operational efficiency.
And the third is all about DevOps and taking everything we've learned in the last 20 years in IEM and making it an integrated part of an API oriented microservices service mesh. So let's jump in to the first and talk about traditional IAM program thinking let's take a step back and think what we've been building in deploying for the last, not 10 or more years. And the first word that comes to mind here is complexity. Sadly identity management technology is still way too complex. And one of the biggest causes of that complexity it's customization, every IM deployment seems to be an exercise in paid extension, right? That's just how it works, but you know, what is the net cost of that individuality? You might say over the time in life of the system and it's huge, right? Go, go look at the budget numbers here. It's sober reading the net cost of doing basic authentication, authorization and governance is staggering.
And, and, and these numbers have got to come down and that's not a poke at the vendors necessarily. It's really a message for the customer, right? For you, for me and for everyone in IAM program management, we drive the use cases here and we set the requirements, right? And, and every customer I've ever met, they select their vendor of choice based on who meets most of their complex corner cases, right? That that's just how it works. But if we peel back the onion a little here, much of that customization and complex complexity really comes from taking a bunch of separate products. They are separate products and work together as a single whole. And if you look closely at the integration between the core elements of access management, Pam, I TSM and IGA, they all work together amazingly on the data sheet, right? That's the way it is.
But when you look carefully at the integration use cases, there's a huge amount of overlap and complexity just consider access request, right? Getting people what they need, who, who really owns that. You can't do it three times, right? Makes no sense. So, so who wins, which one of those disciplines wins. And when you do get below that and deploy the out of the box integration, things are very confusing way too complex, and it all takes just too long to get deployed. And of course, none of this is good for reducing cost and complexity. So in my view, the vendors have to fix this part of the picture. And as an industry, we have to standardize the use cases here and deliver much better integration with much more best practices baked in now to my second helping hand, this one is putting identity at the center of security operations and treating IAM as security.
This shouldn't be hard because if we take a step back, the security plane, as it were, has been heading in this direction for a long time, you might say the first version of that was NETEC right, or, or network security back somewhere, maybe, maybe in the eighties, security really was a network thing. And, and traffic flow was the primary security control plane, somewhere in the nineties, maybe the center of security kind of moved up to the operating system and, and OS that took control. So patching and file level access control was, you know, the real deal and, and SecOps really was the security mindset. And I would say by somewhere in the late two thousands, maybe middle of 20 teen. So the focus moved to be around AppSec, right application security and, and things like the O was top 10. Hopefully everyone's heard of that was kind of the security gospel you might say.
And, and, and everyone really focused on app server security WAFs and CASBY and, and application gateways. And then to today in the shadow of cloud and SAS and, and shared infrastructure, we all seem to now believe that we've entered the time of identity management security or, or IDM sec, the last bastion you might say of, of security control in this highly fragmented service provider ecosystem really is identity management and identity management. I mean, no surprise, right? It controls the session, right? It authorizes the processes and manages the control of users, right. Wherever they come from and wherever they're going. And IDM sec really is the new security control plane seems to be agreement here, but what does that mean for the rest of the security ecosystem, right. For all that stuff that we've already bought and deployed, does it go away? Well, of course not.
It just means that identity and security are now integrated together to create a single security fabric. You really can't do one without the other. I, I don't think so. The question remains, how, how do you do that? So here's my top three, right? The first is around focusing on delivering shared identity context. And this is a big topic for a short session we have today. But so I'll describe it as being a common data model for identities, attributes, and policies, a basic ontology as it were for identity related data that shared across the entire security system. It means delivering a standardized set of restful endpoints and endpoints that can help control where attributes come from, who owns them and who manages their life cycle. And together, this means delivering something that I've always called attribute Providence, and it means defining and sharing a common view of behavioral awareness today, just about every tool in the stack has its own AI, right?
AI and ML. How many times have you heard that? That's great, right. Have to have that technology, but it makes it really tricky to understand who owns what. And I believe the solution here is in some very strict layering and making identity centric baselines, and the data that you get from that belong exclusively to the IAM specific AI tools, not isolating them, but sharing key risk indicators between the layers, sharing the outliers and the events, not the data to promote a common view of situation and awareness. And I guess with that, as I've been saying myself for the last 10, 10 years or more, it really means agreeing on a common model for identity risk scoring. And lastly, putting identity and security together means delivering a series of response oriented services services that are specifically targeted at security into the response. And I'm not talking about crazy stuff here, right?
You could go mad, but simple things like generic session reset, re authentication account suspension, or maybe something like a trust reset that triggers a series of re approvals, you know, basic things that can be delivered as clearly defined identity response behaviors. We absolutely know how to do these things today. And I'm quite hopeful that between the standards efforts in skim and in the open ID shared signals effort, we can deliver these out to the rest of the ecosystem a lot sooner rather than later. And so moving quickly onto my last and final helping hand here for the CS, O let's define an active and integrated role for the existing IAM teams as part of this shift left future of DevOps and microservices and the service mesh. Now, if you're listening there, I, I use the term shift left and this comes from DevOps and, and the world of workload transformation. It's often used as a shorthand for the drive to move test and security processes to the left mirroring. My image is that left. All right, in the entire plan code, build deploy cycle.
Unfortunately, most of the IM technologies we've deployed today they're way far, right? In fact, so far, right. Kind of off the page. And most programs are just super application focused and almost completely outside of a DevOps per view. And this creates a potentially huge problem. I see far too many DevOps and dev SecOps teams reinventing the wheel, right? Redefining the IAM process and buying new standalone tools and services, of course, left unchecked. This is not good for lowering that cost and complexity. We've got to drive alignment here. We all need to better understand what's happening in that composite application and microservices world and drive a strategy that's sustainable over time, obviously super high level picture here, right? So let's quickly dive into a little more detail. I think we got time to do this, but, and let's talk for a moment about identity in the service mesh.
If the term service mesh is new to you, a rather trite way of thinking about a service mesh, it's like the app server of the microservices world. It's the overarching operate model you might say for this decomposed application architecture that's based on containerized microservices and just like app servers. There's several different flavors here to choose from it's. So I it's SIO being backed by IBM and red hat. You've got console being backed by Hashi app mesh from AWS, layered OSM from Microsoft. Doubtlessly be more here. And each of these service mesh systems it's buying, you know, it's really aggressively seeking the developer mind share market dominance, but for all of these different service mesh technologies, there is a surprising amount of consensus here around two key technologies. The first is Kubernetes, right? Everybody seems to agree that Cub, you know, you might say, Cub won the war, right?
Cube won the orchestration war here. So that's good. That's the point of stability. And the second area is around a CNCF project called Envoy. An Envoy is a proxy based container side car that provides a control plane for security and identity. And in the ENVO model, when microservices want to talk to each other, they do so using the Envoy proxy, of course, microservices have to do authentication and authorization administration and audit too, right? And ENVO is the way all that stuff gets executed. Now the emerging standard for VO authentication is called spiffy secure production identity framework for, for everyone. And spiffy defines how to do inter process or authentication using X 5 0 9 MTLS Jason web tokens and OAuth. Now that should sound very familiar, right? Certificate lifecycle, Jos OAuth, IDPs, right? Homeboy IAM stuff, but is your IAM team driving that specification and helping that implementation.
If you, if you started that process and the ENVO proxy model also defines how fine grained authorization gets done too. And there's another CNCF project here called OPPA, the open policy agent. And for those of us that have been around identity for a while, this is basically an optimized respin of Zamal with externalized policy decisions and a common policy language called Rigo also sounds familiar, right? Centralized policy service, common policy, language, you know, IDPs EPS and all that good IAM stuff. And so again, are your IAM teams driving that process? Are they engaged? And are they making sure that everything we've learned around IAM process management and controls gets baked in and done, right? So hopefully you can see why I've kind of dragged this down to this level of detail, right? It's all this new tech and all these new standards, new tools, new vendors, it all comes down to the same IAM best practices that we know and love.
Right? And the point I'm making here is we have to align identity and security across boundaries. The current IAM teams and the current IAM technology has got to engage and grow with this evolution. You have to take, you know, as I've said, everything, we've learned about identity and security over the last 15 years and align it and align it to drive consistency as we migrate from heritage systems like that term to the new world of DevOps and microservices. So rapid wheels up there just about out of time. So let me conclude our session by saying, it's your job. And of course, mine, to deliver a helping hand here to the CIOs O together let's select, deploy and manage a sustainable integrated identity ecosystem. One that's delivering automation and controls and governance with less cost and less complexity. And that's increased the overall value of that current security investment by enriching it with behavioral context and automated security actions. And let's deliver, I am for a new world of microservices and I am that's aligned with that future, but does so by bringing along the history and legacy that we still support in our systems every day. And with that, I think I'm about on time. So I'll pass back to the moderator. I dunno if we have time for questions.
And in September, I was thrilled to join my long term friends here at coing Cole as a research fellow. Now, as I look back, I guess in the mirror as my time as a vendor and more relevantly today as, as the C S O of the public company, I just have to say, you know, wow, basically just an extremely tough job. The role of the C I S O is increasingly a challenging proposition for anyone. And like everyone that sits in an executive seat, you are continually balancing between business drivers, technology change and managed risk. And after speaking with lots of my peers and, and fellow CISOs over the years, I'm not sure that the scales are, are properly calibrate here, cuz when it comes to something like budget security, it's, it's always a cost center, right? How can it not be? And security risk is just so nefarious and so hard to communicate.
It's just a hard driver for a budget conversation. And if you bring that together with no actuary science here or metrics to balance the security, we might say premium against it. It's, it's just tough. And, and even if you could, who, who would you compare yourself to? Right? It, it can't be an internal department, you know, that's not right, cuz they're, they're the customer and it can't be other businesses either. Cuz we still really don't have a way of sharing program drivers and budget a across that boundary. So the CS O really is on his or her own. And you have to ask the question is the board really listening anyway, far too many organizations that I see, they hide the C I S O under it or operations. And you might say the business of security, it, it barely makes appendix K as they say in the board deck.
And it's just a sad, true still that most boards only really wake up to security when, when something bad happens and you know, the DPO or the news is, is, is, is, is pulling us in. So I really am glad to say that I'm an X, C I S O because things certainly aren't getting any easier here with the challenges that are being called that we cause that we're talking about in this conference around working from home and cloud and SAS, you know, and at a drive for zero trust security. I just say, thank goodness, there are events like this, that where we can come together, have a conversation and, and make, try and make sense of it all. Cause of course technology change is inevitable. No one would deny that, but you know, just when we thought we had a handle on client server and web, everything's changing again and the new world of DevOps and composite apps and microservices, it's a ground up rewrite for just about everybody.
And so to mind the, if you like the icing on the cake here really is the fact that the old stuff never goes away, right? We should just stop calling it legacy and embrace it as our runtime heritage. So a tough job being a CIS though, for sure. And that frustration is starting to show stress. Oh yeah. Plenty of that. In fact, really interesting survey by nominee earlier this year, they interviewed 800 CSOs from the us and the UK and they found that 48% of them said that work stress was having a detrimental impact on their mental health. And that stress probably accounts for the atrocious tenure numbers though in the industry today, several reports this year have pointed to the average tenure of a C IO now trending towards 20 months or less. And, and that's just a crazy short time for anybody to be in such a, you know, business critical role, but this isn't a psych conference.
So why have I chosen to open on this thing? And the answer is simple and that's, you can help if you are responsible for security and identity, I've got some program and technology architecture thoughts that can really help the C I S O stay same, a few recommendations on driving an identity centric approach to identity, identity security, to enterprise security that I hope can lower cost reduce complexity and improve overall security posture. So I think I've got about 15 minutes left, so let's jump into three helping hands you might say. And the first is expanding on one of the major themes of this event and that's building an integrated identity aware ecosystem and doing so with lower cost and less complexity. The second is around putting identity at the center of security operations and treating it as security, you know, rather than just operational efficiency.
And the third is all about DevOps and taking everything we've learned in the last 20 years in IEM and making it an integrated part of an API oriented microservices service mesh. So let's jump in to the first and talk about traditional IAM program thinking let's take a step back and think what we've been building in deploying for the last, not 10 or more years. And the first word that comes to mind here is complexity. Sadly identity management technology is still way too complex. And one of the biggest causes of that complexity it's customization, every IM deployment seems to be an exercise in paid extension, right? That's just how it works, but you know, what is the net cost of that individuality? You might say over the time in life of the system and it's huge, right? Go, go look at the budget numbers here. It's sober reading the net cost of doing basic authentication, authorization and governance is staggering.
And, and, and these numbers have got to come down and that's not a poke at the vendors necessarily. It's really a message for the customer, right? For you, for me and for everyone in IAM program management, we drive the use cases here and we set the requirements, right? And, and every customer I've ever met, they select their vendor of choice based on who meets most of their complex corner cases, right? That that's just how it works. But if we peel back the onion a little here, much of that customization and complex complexity really comes from taking a bunch of separate products. They are separate products and work together as a single whole. And if you look closely at the integration between the core elements of access management, Pam, I TSM and IGA, they all work together amazingly on the data sheet, right? That's the way it is.
But when you look carefully at the integration use cases, there's a huge amount of overlap and complexity just consider access request, right? Getting people what they need, who, who really owns that. You can't do it three times, right? Makes no sense. So, so who wins, which one of those disciplines wins. And when you do get below that and deploy the out of the box integration, things are very confusing way too complex, and it all takes just too long to get deployed. And of course, none of this is good for reducing cost and complexity. So in my view, the vendors have to fix this part of the picture. And as an industry, we have to standardize the use cases here and deliver much better integration with much more best practices baked in now to my second helping hand, this one is putting identity at the center of security operations and treating IAM as security.
This shouldn't be hard because if we take a step back, the security plane, as it were, has been heading in this direction for a long time, you might say the first version of that was NETEC right, or, or network security back somewhere, maybe, maybe in the eighties, security really was a network thing. And, and traffic flow was the primary security control plane, somewhere in the nineties, maybe the center of security kind of moved up to the operating system and, and OS that took control. So patching and file level access control was, you know, the real deal and, and SecOps really was the security mindset. And I would say by somewhere in the late two thousands, maybe middle of 20 teen. So the focus moved to be around AppSec, right application security and, and things like the O was top 10. Hopefully everyone's heard of that was kind of the security gospel you might say.
And, and, and everyone really focused on app server security WAFs and CASBY and, and application gateways. And then to today in the shadow of cloud and SAS and, and shared infrastructure, we all seem to now believe that we've entered the time of identity management security or, or IDM sec, the last bastion you might say of, of security control in this highly fragmented service provider ecosystem really is identity management and identity management. I mean, no surprise, right? It controls the session, right? It authorizes the processes and manages the control of users, right. Wherever they come from and wherever they're going. And IDM sec really is the new security control plane seems to be agreement here, but what does that mean for the rest of the security ecosystem, right. For all that stuff that we've already bought and deployed, does it go away? Well, of course not.
It just means that identity and security are now integrated together to create a single security fabric. You really can't do one without the other. I, I don't think so. The question remains, how, how do you do that? So here's my top three, right? The first is around focusing on delivering shared identity context. And this is a big topic for a short session we have today. But so I'll describe it as being a common data model for identities, attributes, and policies, a basic ontology as it were for identity related data that shared across the entire security system. It means delivering a standardized set of restful endpoints and endpoints that can help control where attributes come from, who owns them and who manages their life cycle. And together, this means delivering something that I've always called attribute Providence, and it means defining and sharing a common view of behavioral awareness today, just about every tool in the stack has its own AI, right?
AI and ML. How many times have you heard that? That's great, right. Have to have that technology, but it makes it really tricky to understand who owns what. And I believe the solution here is in some very strict layering and making identity centric baselines, and the data that you get from that belong exclusively to the IAM specific AI tools, not isolating them, but sharing key risk indicators between the layers, sharing the outliers and the events, not the data to promote a common view of situation and awareness. And I guess with that, as I've been saying myself for the last 10, 10 years or more, it really means agreeing on a common model for identity risk scoring. And lastly, putting identity and security together means delivering a series of response oriented services services that are specifically targeted at security into the response. And I'm not talking about crazy stuff here, right?
You could go mad, but simple things like generic session reset, re authentication account suspension, or maybe something like a trust reset that triggers a series of re approvals, you know, basic things that can be delivered as clearly defined identity response behaviors. We absolutely know how to do these things today. And I'm quite hopeful that between the standards efforts in skim and in the open ID shared signals effort, we can deliver these out to the rest of the ecosystem a lot sooner rather than later. And so moving quickly onto my last and final helping hand here for the CS, O let's define an active and integrated role for the existing IAM teams as part of this shift left future of DevOps and microservices and the service mesh. Now, if you're listening there, I, I use the term shift left and this comes from DevOps and, and the world of workload transformation. It's often used as a shorthand for the drive to move test and security processes to the left mirroring. My image is that left. All right, in the entire plan code, build deploy cycle.
Unfortunately, most of the IM technologies we've deployed today they're way far, right? In fact, so far, right. Kind of off the page. And most programs are just super application focused and almost completely outside of a DevOps per view. And this creates a potentially huge problem. I see far too many DevOps and dev SecOps teams reinventing the wheel, right? Redefining the IAM process and buying new standalone tools and services, of course, left unchecked. This is not good for lowering that cost and complexity. We've got to drive alignment here. We all need to better understand what's happening in that composite application and microservices world and drive a strategy that's sustainable over time, obviously super high level picture here, right? So let's quickly dive into a little more detail. I think we got time to do this, but, and let's talk for a moment about identity in the service mesh.
If the term service mesh is new to you, a rather trite way of thinking about a service mesh, it's like the app server of the microservices world. It's the overarching operate model you might say for this decomposed application architecture that's based on containerized microservices and just like app servers. There's several different flavors here to choose from it's. So I it's SIO being backed by IBM and red hat. You've got console being backed by Hashi app mesh from AWS, layered OSM from Microsoft. Doubtlessly be more here. And each of these service mesh systems it's buying, you know, it's really aggressively seeking the developer mind share market dominance, but for all of these different service mesh technologies, there is a surprising amount of consensus here around two key technologies. The first is Kubernetes, right? Everybody seems to agree that Cub, you know, you might say, Cub won the war, right?
Cube won the orchestration war here. So that's good. That's the point of stability. And the second area is around a CNCF project called Envoy. An Envoy is a proxy based container side car that provides a control plane for security and identity. And in the ENVO model, when microservices want to talk to each other, they do so using the Envoy proxy, of course, microservices have to do authentication and authorization administration and audit too, right? And ENVO is the way all that stuff gets executed. Now the emerging standard for VO authentication is called spiffy secure production identity framework for, for everyone. And spiffy defines how to do inter process or authentication using X 5 0 9 MTLS Jason web tokens and OAuth. Now that should sound very familiar, right? Certificate lifecycle, Jos OAuth, IDPs, right? Homeboy IAM stuff, but is your IAM team driving that specification and helping that implementation.
If you, if you started that process and the ENVO proxy model also defines how fine grained authorization gets done too. And there's another CNCF project here called OPPA, the open policy agent. And for those of us that have been around identity for a while, this is basically an optimized respin of Zamal with externalized policy decisions and a common policy language called Rigo also sounds familiar, right? Centralized policy service, common policy, language, you know, IDPs EPS and all that good IAM stuff. And so again, are your IAM teams driving that process? Are they engaged? And are they making sure that everything we've learned around IAM process management and controls gets baked in and done, right? So hopefully you can see why I've kind of dragged this down to this level of detail, right? It's all this new tech and all these new standards, new tools, new vendors, it all comes down to the same IAM best practices that we know and love.
Right? And the point I'm making here is we have to align identity and security across boundaries. The current IAM teams and the current IAM technology has got to engage and grow with this evolution. You have to take, you know, as I've said, everything, we've learned about identity and security over the last 15 years and align it and align it to drive consistency as we migrate from heritage systems like that term to the new world of DevOps and microservices. So rapid wheels up there just about out of time. So let me conclude our session by saying, it's your job. And of course, mine, to deliver a helping hand here to the CIOs O together let's select, deploy and manage a sustainable integrated identity ecosystem. One that's delivering automation and controls and governance with less cost and less complexity. And that's increased the overall value of that current security investment by enriching it with behavioral context and automated security actions. And let's deliver, I am for a new world of microservices and I am that's aligned with that future, but does so by bringing along the history and legacy that we still support in our systems every day. And with that, I think I'm about on time. So I'll pass back to the moderator. I dunno if we have time for questions.
Stay Connected
How can we help you