Episode ten of the podcast, Identity as the Core of Zero Trust, features Dan Miller from Ping Identity, emphasizing that verifying digital identity and assessing user attributes in real time is critical before granting access to any DoD resource. He discusses the importance of using detailed attributes like location, device, and role instead of relying on simple logins to make smarter, real-time access decisions, which is crucial for secure operations in classified and remote environments. Since many DoD units work in disconnected settings, Ping Identity provides local identity solutions that keep missions running and sync with the cloud when reconnected. This episode explores how, in joint missions, enforcing secure data sharing through identity-driven access and tagging paves the way for granular Zero Trust.
Identity as the Core of Zero Trust
[Tom Tittermary]
Hey, welcome to another episode of Zero Trust Given. I am your host, Tom Tittermary, here to have another conversation about zero trust in the DoD. With me, as always, I have my wonderful, fantastic, intelligent co-host, Tom Gianelos.
Say hi, Tom. Hey, good. Hey there, buddy.
And then super excited today, we have a very special guest with us today. From PING, we have one Mr. Dan Miller. Dan, I'll give you an opportunity to introduce yourself.
[Dan Miller]
Hi, everyone. Dan Miller with PING Identity. We run our federal government sales organization and have been in the federal identity space in cybersecurity for over 20 years.
[Tom Tittermary]
Well, very cool.
[Dan Miller]
I won't say much longer than that, but don't want to age myself prematurely.
[Tom Tittermary]
I feel like the average for guests that we've had in here is 20. And you notice from the references that we make sometimes. So if there are folks out there that are regular listeners, one, thank you.
But two, I will just apologize. I made a press your luck joke yesterday about no whammies, no whammies, no whammies. Stop.
And four people in their mid-30s looked at me like I had a second head because the references, that's a mid-80s game show. You can YouTube it and then you can be part of the joke here. But no, Dan, we wanted to have you in today.
So a lot of times we'll have folks into the show and what we like to do is zero trust seems like a super big nebulous concept. Where do I start? Where do I go?
Right? So breaking it down into individual pieces because it takes a village. It takes a whole ecosystem to deliver zero trust.
What we really wanted to have you in today is the identity pillar specifically. We do a ton of work with Ping out there in the field with the DOD. And we just wanted to bring a little extra color, a little roundness, some granularity to that part of the conversation.
So just teeing it off. So how are you seeing Ping influence, affect, and help the DOD customers in the wider area, the DIB, the civilian government, the customers that you're helping and kind of nail down that identity piece of that zero trust pillar?
[Dan Miller]
Sure. First, thanks for having me. So identity, we believe, is critical to zero trust.
If you can't, one, confidently, with a high level of confidence, identify somebody and who they are digitally, nothing else really matters. And two, just because you've been identified digitally doesn't mean you should have access to certain resources. So again, in the zero trust framework of always assuming breach, looking at attributes that users have to determine access.
And those attributes can be anything. So from an identity perspective, we're one of a number of different technologies that kind of fill that space for the identity pillar. And they're all really critical and important.
But what Ping Identity does with the identity pillar is really it's establishing who you are and then what you're allowed to see and providing that secure access to those resources, whether you're on premise in the building, on your phone, traveling, et cetera. But again, based on attributes, there may be scenarios where if you're not in the building, you don't have access to anything. You know, think about detail and skiffs.
If you're on the unclassified network and you're traveling remote, are you in countries where it's okay to see that data or are you traveling in countries where you shouldn't be getting access just by the sheer nature of where you are? So from an identity perspective, we provide that high level of confidence that you are who you say you are and we're looking at your attributes to determine what you're allowed to see and what you're not based on any given point in time.
[Tom Tittermary]
We've had the conversation a number of times, right? So if I take 19 steps back from zero trust as a whole, there's a massive amount of policy decision point data that gets collected, right? And this is from host, this is from identity, this is from any wide number of sources, they could be from network sources, and then all of that goes into a SIM, really smart people or AI machine learning do analysis, they establish risk, and then the policy enforcement point on that comes out of the other side.
Does this person or thing get this resource? So data, application, assets, or services on the far side, right? So we're super high level, ton of data coming in, a bunch of hashing happens, and then a decision gets made and a policy is enforced on, does this person or thing get this resource, right?
Data applications, assets, or services. So, I mean, from the ping side of the house and a lot of the work I do with ping across DOD, it's really invaluable the amount of data that we can get to enrich that risk score around the users, like specifically around the attributes we can get. I think the word identity means, oh, people assume it's like showing an ID card and it's your name, and it's like, well, no, Dan's good.
No, but is he good today? Is he good here? Is he good in this building?
Is he good in this context? And by the way, all of those attributes, can I map that down to a certain sensitivity or data or a certain class of data? Could you just talk a little bit about how you're using that rich data to help people make those decisions easier?
[Dan Miller]
Sure, yeah, and for those that may not really understand identity or this concept, think about it from, you know, I'll break it down to the most simplistic form, right? If that's okay from, you know, you're 21, 22, 23 years old, you're going to a bar or a concert, right? You have to be 21 to get in.
You show your ID, you're allowed in. But now there might be, you know, standing room only. There might be tables.
There might be a VIP area. Just because you're old enough to get in, you pay the entry fee, doesn't mean that you're allowed access to the VIP area. So that's the same type of concept with attributes and that data about identifying someone and then enabling what they're allowed to see and what they're not allowed to see.
So using that richness of all the attributes about a user helps the organization to get really fine-grained access control, attribute-based access control to their resources.
[Tom Tittermary]
We kind of teed this up yesterday when we were, folks that listen don't realize like we talk about what we're going to talk about. It doesn't sound that way, but I swear we do. But we were having a conversation talking about what we were going to talk about yesterday and we got into the topic.
And we get into this topic pretty regularly about, you know, cloud and local, right? So everybody looks at individual cloud services and they say, wow, the scaling is great. We like the SaaS structure of things.
I like that I don't have to patch and manage. But I, and by the way, Tom and I work for a cloud company, right? There's scenarios, you know, especially in the DoD case where you're going to need something local in many cases, right?
DDEL is a great example we've talked about before, but we were just teeing it up yesterday. And I talk about how we partner with different folks in the industry to kind of marry that hybrid scenario between having some level of scalability with cloud, but having local presence. Do you want to, do you want to touch on that a little bit and then we can elaborate?
[Dan Miller]
Sure. You know, I mean, cloud is great. It provides valuable services to the government, to the DoD.
But to your point about DDEL, especially in the Department of Defense and the intelligence community, they're not always connected to the internet, right? If you're in a forward deployed position, right? That's a situation where you don't necessarily want to be connected to the internet or you want to have limited connectivity just to get orders, information, next steps, et cetera, but you don't want all your rest of your data out there in the wild, right?
Or available to anyone. So having a confined environment and being able to run and use the latest information to provide access to resources for the soldiers to be able to execute their duties is really critical. And think about ships, right?
You think about ships in the middle of the ocean or submarines on the, you know, underneath the sea, right? Where they're not going to have connectivity. They've got to be able to operate in an autonomous self-contained environment.
But when they come back up to shore, they need to be able to plug in, get all the latest, greatest updates. So having technology that can run in a DDEL closed off environment and run completely autonomously on its own is super critical. But being able to plug back in to get all the latest, greatest updates is also very critical.
So one of the things that we're very proud of is the fact that in our SaaS environment and our on-premise software environment, everything is the exact same, right? The GUI is the same. The policies are the same.
You know, the SOP for your users is the same. So you're not having to teach people anything new. And then when you plug in, you're just getting all the latest updates on the users, the policies, et cetera.
[Tom Tittermary]
Yeah, I think that we're approaching DDEL much the same way. So I constantly have the conversation about, yeah, Tom, what happens when the cloud goes away? So we have a DDEL solution and I won't get into too much detail about it.
But I think people don't run the math all the time that DDEL means I lose all of my enterprise services because I don't have cloud connectivity. So like 365 or unless I've got a local component of those individual things, I've got to have some level of replication of those services inside my own shop. And then that gets really daunting when you start looking at 152 activities relative to the zero trust.
I got to bring all these things into the technical environment. So especially if you have to manage them specifically in the environment, like the way that we do it is we talk about we have individual pieces of hardware or virtual machines that we can bring down that are an extension of our cloud. So you could either do these services in the cloud or bring them into that tactical component.
And then when the cloud goes away, they will act independently. And when the cloud is there, then they're getting constant updates from the cloud. Right.
But in this scenario, the conversation I always have to have with folks in detail is, well, yes. So you need this private cloud controller from Zscaler to do deal with Zscaler. And they go, OK.
And I go, what's your local identity? And they go, we don't have one. Most people have some type of local identity.
Right. But it's like they haven't thought that out in an individual tactical scenario. So then the question is, well, how do you plan to do zero trust in detail?
Are you just going to fail open or is it just perimeter at this point or is it like are we back to anybody on the network gets access to things and that there's a slight disconnect there. But a lot of the folks that I work with, you guys, especially in the identity space, like we're solving that problem with you guys, because that our solution in the tactical area needs to be able to hit a local identity so that I can go punch that new tunnel, create that zero trust connection locally.
[Dan Miller]
Correct. Absolutely.
[Tom Tittermary]
Yeah.
[Dan Miller]
And we are doing that right. And there's a number of different ways. A number of different approaches to take all at the same time, one of which is just having a local local directory that synchronizes with your master, and that's good from, you know, a making sure that the users have the right reason to access certain data and being able to justify that, share that in audits, et cetera.
The other part that's just as important is being able to remove those users when they're no longer part of the organization, whether they've retired, whether they've been let go. Whatever the scenario is, you want to be able to off board them as well. So you don't want to have users that are still part of the environment that haven't been there for six or 12 months.
I think that's a challenge that that the Department of Defense is definitely having today, you know, reaching up to to DISA and DMDC. And, you know, they're doing great stuff with onboarding users and being able to show why users have access to certain data. But where it seems to have a challenge with some of the major commands and Mildeps is how are they off boarding those users and getting rid of the users that are no longer there and that shouldn't have access?
And that's not just a challenge overall, but it's a big challenge on the detail side, too, because if you're disconnected a lot of the times, how are you doing that? So you need to be able to have some type of directory or some type of approach to be able to synchronize both the new users as well as the old users that shouldn't be there anymore. And then having all that data with the attributes about the users and what they can see, whether those attributes are stored in the directory, whether they're stored within Zscaler, whether they're stored somewhere else, being able to grab those attributes to make real time access decisions based on those attributes.
[Tom Tittermary]
Yeah, one of the things I run into a fair amount is is hygiene in systems over time. Right. Like, Tom, what was the last time that you talked to somebody that said, well, so Tuesday from two to four, I'm doing all my firewall rule hygiene and I'm going to clean up all the firewall rules.
And I'm going to so these something will get put in somewhere to allow an activity that's critical at the time. But then there isn't that circle back in a lot of those cases. The way we do it in Zscaler is I could put a timer against I'm going to grant this individual user access to this application for this amount of time.
And then, by the way, I'm going to send a notification a week before, two days before, one day before, and then they individually lose access. But it's almost something I would I would rather see or I would really like to see an individual duty requirements around implementations of systems, especially in the zero trust context. Because you could do something with the right intention for the right mission context at the right time.
And then later on, if that cleanup doesn't happen now, I've exposed, you know, data assets, resources to someone in a context that isn't appropriate for that case. Right.
[Dan Miller]
Right. Absolutely. And at the very least, even if it doesn't cause issues, the government's paying more money than they should from a licensing perspective, too.
[Tom Gianelos]
True.
[Dan Miller]
So in today's world, with those and looking at efficiencies and looking at cost effectiveness, if you're not doing that data cleanup, you're likely spending more money than you have to on an annual basis for some of these resources. Right. We see that a lot.
[Tom Tittermary]
Yeah, there's definitely a fair amount of that out there. One of the other things I wanted to talk about, so we've kind of gotten into the local IDP. There's a number of different tactical scenarios, right?
And details, a big one, too. One of the other things we were talking about talking about is this the how this how does this all move? I have a lot of really complicated conversations around mission partner environment, and it tends to change a little bit by COCOM.
Like, it's a very different conversation when I'm talking into PACOM versus when I'm talking to UCOM.
[Dan Miller]
Correct.
[Tom Tittermary]
In a lot of different ways. Right. And there's some of it is almost more like national personality related and history of nations relative to their interoperability together in context.
I don't want to I'm not going to say anything more than that.
[Dan Miller]
Right.
[Tom Tittermary]
I'm going to start a flame war somewhere. But I so I'm going to I'm going to call out and I'm going to I'm going to just totally bless my ignorance here. I'm not the world's biggest identity expert.
I tend to focus more on the network and the core cyber side. We were talking about, you know, SSO and federation and and how that applies to that mission partner context. I don't want to make you say everything you said before, but if you can give some of that color here, I think it'd be really useful.
[Dan Miller]
Sure. So from a mission partner environment. We're looking at providing access to.
Sensitive data that's been released that mission partners can have, maybe it's not released, maybe it's still classified to some level, but we're working with our mission partners, other countries to provide access to these resources and and collaborate with them. Right. So you set up federation agreements with these other countries so we don't have to issue them credentials because we don't want to be in the business of issuing foreign countries credentials to see our data.
We'd rather have that trust agreement from a federation perspective where you create a trust agreement between the United States and Australia, the United States and the UK with Germany, France, et cetera, all of our mission partners around the globe. And that trust agreement establishes, hey, how does the U.S. want a user to authenticate? Right.
If you're coming into the U.K. with a username and password, maybe we're not going to provide you anything. You've got to have some level of multi-factor authentication. And that trust agreement that gets set up to say, hey, you know, the U.S. is going to trust the Australian government if their users authenticate with multi-factor authentication. And then you send us, you know, any of these 20 attributes in a federation token. And those attributes, along with how they've authenticated, are going to determine what access to resources they have. So that's part one is establishing those trust agreements between nations.
The second part, you mentioned SSO and federation. To me, SSO is, I'm going to come in, I'm going to authenticate to see all of my applications, right? I'm going to authenticate once and I'm going to get access to these 10 or 15 applications that I use on a regular basis.
And usually that's done within my organization. So I come in to work every day and I authenticate and I see my Ping doc and I have all the applications that I can see that I use on a regular basis. That's kind of single sign on, right?
I authenticate, Ping has all of my data, my username, my password, my multi-factor authenticator, etc. They have all of that information. So that's what we would say is single sign on.
In a mission partner environment, there are cases and there are reasons why we don't want to store foreign nations user data in our directory. Many of them don't allow it. Or if you're going to do it, they want to have the rights to audit your system.
So we're certainly not going to let foreign countries audit our military system. So federation becomes super critical. And when I say federation, I mean you're allowing access to resources based on a federation token, right, that has all of this attribute information contained within that token to provide access for that user.
But we're not persistently storing that user data. That user data would be in memory for the session. It's configurable, but it's usually for the session.
So that way, the user and their attributes determine what they have access to. And then once the session ends, all of that data is gone. And so that's super critical from a mission partner environment, A, to provide the access that they need based on who they are and what their attributes are, most importantly, and then making sure that that data around the user is gone once the session has ended.
[Tom Tittermary]
Yeah. So in that case, one of the one of the interesting things, like, again, we we talk about identity and a lot of people think of the, you know, I'm getting into the I'll say the concert versus the bar with the ID card. And it's they just go against the individual name and 21.
And sure. But the granularity of the assets, I don't know. And a lot of the conversations I've had that people make that I think there's identity people.
And then I think there's data authorization and tagging people. And I don't know if they collaborate in my experience as much as I would. I would probably like to say I've called out a number of times that I think, like, really accurate, clean data tagging is one of the things.
It's like one of the biggest speed bumps between the DOD meeting zero trust initiatives by twenty twenty seven. Because data is data is getting produced at a rate much faster than humans can accurately tag it. But the ability to, you know, the way that I've tagged data cross pollinated with the individual attributes of a user.
That's how I get super granular about should this person in this context, in this place, on this device have access to this specific piece of data? And that could be megabytes out of zettabytes. Right.
[Dan Miller]
And I think there's one I agree with you. And I think there's more than two scenarios, but I'll give two large scenarios. One, there is accessing the data in an application.
And that can be controlled just through attributes without the data tag, in my opinion. Then there's the OK, I've taken this data and I've put it into a Word document, a PDF or some consumable format that I can then share with others. That's where I think data tagging is really critical.
And so I think you're right that the data tagging vendors and the companies like Ping haven't collaborated enough. But we're starting to we're actually working with a few data tagging vendors today where if the data is tagged, they're leveraging federation technology. Right.
Whether it's SAML or OIDC to do that. So if a data tagging vendor is leveraging federation capability and a user clicks on a link to download information about three different nations, well, maybe one of those nations says, hey, if you're not a U.S. citizen or a U.S. DOD employee, you're not allowed to see this data. Right.
So only U.S. This is for only U.S. citizens or U.S. Department of Defense personnel. But the other sets of data is allowed to be seen. So if the data is tagged properly through our technology, you would be able to actually scrub out the data that says it's only for U.S. citizens if you're, say, a Canadian officer. So you'd still be able to get part of the payload that you need to see, but you're not going to get the payload that says you've got to be a U.S. citizen. So I think that we're seeing the coming together of these technologies and we're starting to work together more and more, which will definitely help from from reaching those zero trust goals. But I still think we're a long way away.
[Tom Tittermary]
I think part of it that isn't immediately apparent to a lot of folks is when we talk about mission partner environments, not all of our friends are friends. So you you will work together with a number of mission partners against an individual mission goal. However, your individual mission partners might might want the data they contribute to the mission to be tagged a certain way because I can't have those guys seeing it.
Right. And I'm not going to I'm not going to name out individual countries here, but you can you can create your own conclusions here. Right.
But that's one of those critical parts of tagging. Absolutely.
[Dan Miller]
Right. And to take it a step further, maybe it's not us. Right.
Maybe it's our mission partners. Right. We have two over here on the left and two over here on the right.
And they're they're partners of ours, but they're not partners of each other's. Right. And so you want to make sure that, you know.
Country A on the left and country D on the right aren't seeing each other's data. Right. So that type of protection is pretty critical as well.
[Tom Tittermary]
Or it's being it's delivered as an enriched product in the mission context where the full data set is not available. However, the mission instructions that were based on the data are available to be able to coordinate in the same way.
[Dan Miller]
Correct.
[Tom Tittermary]
Yeah. The data tagging piece like consistently is is one of those super interesting ones to me because you end up you were talking about application data versus file data. Right.
And the way I'll usually break it out is that I've got unstructured data, which is, you know, PDF files and any individual file. Right. That'll share out the way that you're talking about.
And then I've got something that I we used to call it semi-structured. I'm not sure if people still do, but something like 365 is this is a database that is full of unstructured data. It's a structured data set that is full of unstructured things.
And then you've got structured on the far side. So structured being it's an Oracle database. And but this could be the database application back end to, you know, the one of the applications that you're talking about.
[Dan Miller]
Right.
[Tom Tittermary]
So the data authorization around that piece of it gets interesting. Like there are folks that I'm friends with in industry like Immuta that do some really interested structured obfuscation that'll block even through the application access. Right.
And then Microsoft actually does a really good job in 365. I've said 365. I can say Microsoft.
They do a really good job in their own internal data set to be able to tag and allocate access that way. How are you from a ping perspective? Are you seeing the attributes that you guys are building out with customers?
How are you seeing use that to enrich and make really granular the users that they want get have access to the data they want just in the right time? I know you were talking about a little bit more interaction, but are there any starting notions there? And where's that going?
[Dan Miller]
Yeah, that's a good question and a lot of answers on that one. I think we could probably spend a few hours just on that topic alone. Right.
At a high level, we're going to provide access or prevent access based on attributes to applications. And then when you're making outbound API calls to say data repositories. So if you're making outbound calls to that unstructured data to pull it down into a PDF or into some readable format at that time of the API calls, when we can look at the attributes to say you're allowed access to this or you're not allowed access to this.
And it can be one API call, it could be 20 different data repositories that you might be pulling from. And we can monitor and provide access or deny access to all of those. Once it gets into the file format of a PDF or into an email or into something else, that's where we would need the help of the data tagging vendors to be able to make informed decisions on that.
Not sure if that answers the question at a very high level or not, though.
[Tom Tittermary]
No, I think it does. Right. It gets down to the the individual tagging piece of it.
I've talked on another. We had AJ from Verona's in here and I got on my soapbox about how the DOD needs like a taxonomy for data tagging. And I did the whole.
If you listen to that other episode, I apologize. I'll say it again, but like we need a kingdom file and class order family genus species for data at a top level down, because I think a lot of times tags are created, but they aren't inherently created in an immutable structure that can't change. Like when they find a new animal, they don't create a new structure, pick a title outside of the existing structure or any living thing.
Right. It has to fit somewhere inside the standard immutable model. I just I haven't necessarily seen that in a lot of the conversations I've had.
[Dan Miller]
I haven't either. Not with data across across the board in the DOD. I think everybody has their own process and they're all very, very similar, but they're not the same.
[Tom Tittermary]
I feel like that's one of those. I hate to. People are scrambling to meet, you know, the data tagging requirements by 2020.
And like the suggestion to take three steps back, create the structure is like, hey, Texas wants to potentially move forward faster. But I, I, my biggest concern is if I'm going to super cleanly map attributes to tagging, then I need to have an immutable tagging mechanism to know what all those individual things are, to be able to map them back to attributes.
[Dan Miller]
Completely agree. Completely agree. And that's the challenge, because there's so much data out there.
Where do you begin? Yeah. Right.
And I think that's the struggle that organizations have. There's no easy answer. I don't think there is one answer either.
Right. It's every organization's got to determine how they would be able to do that in the best way possible.
[Tom Tittermary]
I think one of the other interesting things we've had a couple of folks on. Look, we had John Paul from GuidePoint. We had the folks in from Red River Quint who runs their DoD team.
He's got my job over there. And we had really wide areas, Zero Trust conversations with them about where do you start? And I think one of these, there are so many different chicken and egg interactions in the Zero Trust puzzle that people have a hard time and they go, well, I want to go figure out identity before I do X, or I want to get my data tagging together before.
What's the identity going to do if the data tagging is not there? And then from a Zscaler perspective, it's I need to figure out my identity and I need to qualify all my applications before I start putting in. But it's one of those things where I don't think the answer is.
I see people heading down one trajectory at top speed around one of the pillars and they go, when I get this one done, then I'll go over to the next one. But I almost feel like there's more of a need. And I've made more progress faster with people that are doing a little bit in different areas around, you know, crown jewels in a couple of areas and then kind of moving up organically as the whole thing.
[Tom Gianelos]
Through a serial versus parallel process.
[Dan Miller]
Right. Yeah.
[Tom Tittermary]
Yeah. It's I think that and one of the things I run into also is a lot of the different pillars relative to Zero Trust are different organizational structures or commands in individual military service branches. So it's hard for it unless it's in a policy layer at the, you know, at the RBCIO level.
Leo Garcia, really smart guy. I just talked to him. It's it can be really hard to in a lot of those cases.
Implement down in a forceful way outside of of standard policy and get that, you know, that group interaction, a demand of individual group interaction working to kind of build that up from the grassroots.
[Dan Miller]
You're right. And I think the struggle is too many people overanalyze where do we need to start. I think the most important thing is you pick a place to start.
You start. If I just look at the identity pillar, you can look at, you know, two different areas where people tend to have a hard time choosing where to start. Right.
The IDP, the identity provider or the identity governance. Do I need to create all of my entitlements, all of my permissions, all of my roles first? Or do I need an identity provider to create the identities and have the master user record and have all of this stuff before I do the policies, the entitlements, permissions, et cetera.
And the reality is, is that depending on the vendor, they're going to tell you you should start one way or the other. But you can start either way.
[Tom Tittermary]
Everybody wants to get their PO first.
[Dan Miller]
Correct. And hey, that's that's what we get paid to do. Right.
So, of course, we're going to say that. But the reality is, is you just need to start in one. You just have to pick where you start.
Sometimes you can pick both. Right. Have two different teams work these in parallel.
To your point about parallel and serial. Right. You can do them in parallel and then bring them together.
Or you can start one and then do the other and then bring them together. It's just organizations just need a place to start. And they need to just say, this is where we're starting.
This is what we're doing. And here's our plan. As opposed to just overanalyzing and you get the paralysis by analysis and then you never get anything done.
[Tom Tittermary]
Yeah, we the part of the Red River conversation we had was they do a really interesting like zero trust assessment across agencies as a whole. Right. And they run across the pillars and they do the red, yellow, green.
I think we said red, orange, green. That might have been James Carnell. He's an Australian guy.
They say I don't know if they say red, orange, green. Anyway, just listen. That episode was a good one.
But we were having that conversation. And I think that the initial notion of that. So there's a couple of things there.
So one, red, yellow, green is better than checkbox, not checkbox. A million percent, because we talked about individual granular requirements. And it's like, do you do DLP like there?
I'm positive that there are people out there who are going through their zero trust documents saying, well, I do DLP in this one place in this one product for this one thing. Not thinking of structured, not thinking of semi-structured, not thinking of. Right.
It's not it's not holistic. It's not the spirit of the law. It's the letter of the law.
Yeah. I checkbox that. Right.
But to be able to take that and go, well, it's orange. I'm doing a really good job here, but I haven't really started over here. And that's a place that I need to put some focus.
But I think that having that perspective of being able to you want to start with red and you want to get red, at least orange, and then you want to try to prioritize your oranges to get them to green in some way.
[Dan Miller]
I would agree. I think that is a much better strategy than just the black and white. Yes.
No. Because what are the levels of yes, no. There aren't any.
It's either yes, we did it or no, we didn't. To the point of yellow or orange. You're you're doing something.
[Tom Tittermary]
Yeah. And we are in the in cybersecurity. We are not in the practice of eliminating risk.
We're in the practice of mitigating risk. So how do I do the most good? And there is there's definitely a I might be starting something here, but there's absolutely something in industry where there's a there's sometimes, I might even say often, a gap between compliance and effectiveness in terms of people.
A lot. And I believe me, guys, I feel for you that are out there in the duty specifically where, you know, one hundred and fifty two activities or if you're in the DIB and you have, you know, an ocean of CMMC controls, you know, the ability to check the box for the auditor to make sure that you are compliant under an individual scenario is is real. And I don't want to take anything away from that.
But I think a lot of times in the effort to check the box, people take a couple steps back from the use cases. Like, why does that matter and how does it matter to the warfighter in some of those cases?
[Dan Miller]
Yeah. And if you prioritize from that perspective, it helps you identify where you need to start. And I think you're right, it's cyber security is about risk management.
What is the acceptable level of risk within our environment to make sure that our data is safe? And, you know, I've had conversations over the years with many CIOs and and leaders of organizations. And early on in my career, it came to, you know, I came upon the realization that, oh, wow, cybersecurity is really it's about risk management.
It really is. And it's just a different dynamic and a different way to think about it to say, put the warfighter as the primary figure and the primary concern. How do we do what's right by the warfighter within our organization and within our environments?
And I think that can help prioritize, because to your point, I think we do as as people, right, we get caught up in, oh, I'm having this audit, I've got to pass this, et cetera, et cetera, et cetera. But if you take the approach of, hey, I need to protect the warfighter, we need to do what's right for them and what's right for the mission. And then you work backwards from there.
Hey, maybe you're maybe you're 80 percent, but that 80 percent is the most important as opposed to trying to get to 100 percent or 90 percent where you might miss something that's more important.
[Tom Tittermary]
Yeah, I have a really good friend who's I won't say his name, but he's he's at a large bank in the in the risk side of the house. And when he and I talk about I.T. and we talk about risk, everything eventually makes its way down to calculable business risk relative to an individual scenario that gets compared against the cost of the security program, people, products that go against it. And if the cost of the process is more than the risk to the business, then typically that's not something that's executed upon.
But now you like that's a very standard. I feel like that makes sense to a lot of people in the in the private sector side of the house. But then you try to go have that conversation with the O.D. and there's five guys in a foxhole and risk is a very different calculation and decisions might might get made very differently, like allowable risk from a security operations perspective in a like a live fire environment is one of those things where it's like, well, you know, the calculation is totally upside down and things just need to happen the way they need to happen when they need to happen.
[Dan Miller]
Yeah, you can't calculate that operational risk like banks do. I mean, ultimately, from a cybersecurity perspective, you know, when you and I worked together many years ago in the DLP space, you know, the banks look at everything from a how much does it cost to get a new customer?
[Tom Gianelos]
It's quantifiers qualify.
[Dan Miller]
Correct.
[Tom Gianelos]
Yeah.
[Dan Miller]
But operational risk in a military sense is completely different. How do you measure that?
[Tom Gianelos]
Right.
[Dan Miller]
How do you measure the life of five guys in a foxhole? Right. Or the value of the lives of five guys in a foxhole.
It's not you can't compute things the same way. You've got to have a completely different mindset.
[Tom Tittermary]
Yeah. And there are. So it's interesting.
And we were having a conversation that the part where we were talking about local versus cloud to like part of that risk calculation is in those scenarios, sometimes the decision to detail or not detail very specifically as part of the risk calculation, because if I'm accessing a cloud service, Oconus, I'm putting some level of signal into the atmosphere. Right. And that signal might exceed the risk of the value of the individual cloud platform, which is literally why like self-imposed detail in some of those cases.
[Dan Miller]
And there's a difference if we can control that signal and we can control where that signal goes, as opposed to we're riding on somebody else's. Big implications on that side of the fence as well.
[Tom Tittermary]
Yeah. There's a I'm just going to say this out loud. There are millions of Zscaler business users globally.
That if you use the Zscaler service and you make your first top Zscaler, you'd look like an international business user. Just going to I'm just going to throw that out there. Regardless of what you're doing, you're going to look like all the other Zscaler international business users.
[Dan Miller]
Right. That can either be a good thing or a really bad thing. Yeah.
Depending on the context.
[Tom Tittermary]
It's got its bonuses in some cases.
[Dan Miller]
Yeah.
[Tom Tittermary]
There's a there's a mission context for that sometimes. Well, you get into allowable risk and compliancy against policy, against mission value. And in some of those individual cases.
So we were talking about data authorization a little bit. Are you seeing any new policies relative to, you know, identity standards relative to the DoD, where there are some level of requirements that are that are timestamped or not about individual things DoD components need to know relative to policy around that identity space?
[Dan Miller]
Sure. Yeah, we actually are. And it's not new, but there's a policy out there right now from DoD OCIO that says every every organization within the Department of Defense needs to connect to one of the seven approved identity providers within the DoD, right?
DISA, Army, Navy, Air Force, et cetera. And so organizations are scrambling to try to do that. And I think that's a big challenge for them.
And it's and it's fairly daunting if you look at it. So what do you mean by connecting to an IDP? What we mean by that is if somebody is going to connect to the Navy as an IDP, right, maybe let's pick like Navy Bureau of Medicine as an example, they would need to change how they authenticate their users today.
So if they're authenticating their users locally today, they would need to point all of their user authentications to Navy Identity Services to do that initial authentication. And then once that authentication happens, a federation token gets sent back to Bureau of Medicine and they use the information in that token as the authentication into all of their applications. There are a lot of challenges with that.
If we just look at one organization, now I don't know how many applications Navy Bureau of Medicine has. I don't know what they're doing today. So this is all hypothetical from other organizations that we've talked to.
But let's just say they have 300 applications that they use across their, you know, the Bureau of Medicine enterprise. Do all of those applications support federation protocols? Chances are half of them will and half of them won't.
Or some variation thereof. So the other part of that is Navy Identity Services. Do they want to have 300 applications from Navy Bureau of Medicine connecting into Navy Identity Services?
Probably not. They probably don't have the manpower to onboard 300 applications times X number of organizations that have to connect to them, right? They don't have the manpower to do that.
So that's challenge number two, right? So you have challenge number one of, hey, maybe not all my applications support federation protocols like SAML and OIDC. And Navy Identity Services may not have the manpower to actually onboard all these applications.
Then the third challenge would be, well, what about authorization? The IDPs are only doing authentication. They're not doing authorization.
So then how do you do that? So what we're seeing as a very good solution to help, A, expedite the time frame that people connect to the seven approved IDPs and, B, still maintain the control of their applications and their users and the authorization to that and being able to connect all of their applications, not just modern applications that support modern protocols, but legacy apps. And most of those, many of those legacy apps are mission systems, too.
So, which are very critical. So instead of having all of your applications connect to one of the seven approved IDPs, which we pointed out the challenge is, why not have a local identity provider that then connects to one of the seven approved IDPs? What that's going to do for organizations is, A, it's going to be one connection.
So it helps the IDP. It helps my local organization, right? You create that one connection.
You get one protocol. Your local IDP should be able to translate federation protocols. So what do I mean by that?
If I'm receiving a SAML assertion, right, the Secure Access Market Language, I think that's what that stands for. Please check that and if it's wrong, delete this. But so if you receive a SAML assertion, but your application requires OpenID Connect or OIDC, we can translate that and provide the application what it needs.
So now you've got a way to, A, support all your modern applications that support all your modern protocols, SAML, OIDC, OAuth, et cetera. And then you also have a way to connect to your legacy apps. So you can put a reverse proxy in front of them with a gateway to then provide those applications.
You know, many of those applications require things like a header injection or something like that. We can do that for them, make sure the application has what it needs. And then from an onboarding perspective, having some self-service capabilities that get you 80% of the way there that you can have the application or business owner do, as opposed to the ICANN team, the Identity Credential Access Management team, take that workload off of them, put it to the various different business owners of your 300 applications.
And then the identity team only needs to do a couple of steps to then onboard applications. So you're making things easier for the IDP. You're making things easier for yourself.
And you're providing self-service to the application owners to help expedite the onboarding of all those applications. So in my opinion, I think that the MILDEPs and the major commands need to have their own local identity provider that can then connect up into the main IDP, because then you get into that next step after that of the authorization, right? And that's what part of our conversation was today was, hey, how do I look at all these attributes?
Maybe the identity provider is providing me 20 or 30 different attributes, but maybe that's not all the attributes my applications need. So if I have a local IDP, it can then help identify what those other attributes are that I need to make decisions with and be able to query those data repositories so I can make those decisions, even if I am using one of the identity providers that doesn't have those attributes.
[Tom Tittermary]
So I have one more question. And again, I revel in my own ignorance, and I'm hoping you can fill my gap in understanding here. So where my brain immediately goes is we're talking about a one-to-one scenario where there is a local IDP that is going to reach up into one of the seven, you know, validated IDPs, right?
In the context of the COCOMs, is it the same scenario, but a local IDP reaching out to multiple? So it would, let's say in the context of SOUTHCOM, so it's going to hit Army, Navy, Air Force, right? Would it work in that way, or is that functional?
[Dan Miller]
That's not my understanding. My understanding is that they would select one of the IDPs to use, right? It could be DISA.
It could be Army.
[Tom Tittermary]
DISA would be the way to go.
[Dan Miller]
They're going to have all the keys. And so, you know, DISA would be logical for the COCOMs, right? But even if it's not, the IDPs should have all of the user data, right, that they need from the Department of Defense.
So if they're going to, if one of the COCOMs is going to use somebody other than DISA, you would have to make the assumption that that IDP would then be able to grab all of that user data from either DISA or the MDC for the users that are within SOUTHCOM, as the example, right?
[Tom Tittermary]
Is there a possibility for the local IDP to federate parts of the seven, like we would a mission partner in that context? Or is that possible, just not the way people are going to go after things?
[Dan Miller]
It's certainly possible, right? The Department of Defense is standing up a federation hub environment to be able to do that, that exact thing. But I don't think it's ready for that yet.
I think their first step is just having all the organizations connect to one primary IDP. And again, I think you're right. I think the logical thing for the COCOMs would be to connect to DISA as the IDP because of the data that they have across the entirety of the Department of Defense.
[Tom Tittermary]
It's, it's, I was having a conversation with one of the newer folks at my company the other day, and it was just like a kind of a wide area career discussion. And it was like, how do you know, like, you're at the right place? And I told him, I said, my three are, and I'll stay wherever I am for as long as you want me, as long as, so one, I'm working with brilliant people.
Two, I'm working on challenging problems. And three, the solutions matter. And what you just, when we talk about the COCOMs, it's always those three.
Like, it's constantly brilliant people. They're always detail, tactical, federation, mission partner. Like, they're always super challenging problems.
And man, did it, like, are you going to find something where the solution matters more?
[Dan Miller]
Right.
[Tom Tittermary]
So it's, yeah, I very much love working with the COCOMs. I couldn't agree with you more on that.
[Dan Miller]
And it's always, not only is it always challenging, but it's always unique and interesting as well, right? It makes what we do for a living a lot of fun.
[Tom Tittermary]
The number of times that I've had conversations with that community about, well, that's not what we built it for, but yeah, you could use it for that is so many, right?
[Dan Miller]
Indeed. Yeah, it really is.
[Tom Tittermary]
Yeah. Well, Dan, thank you so much for coming in today.
[Dan Miller]
Thanks for having me.
[Tom Tittermary]
And I, it's funny. I know that asking dumb questions is how I get smarter in some ways, but I appreciate you being considerate with some of my dumb questions in the topic. And thank you so much.
For those of you out there listening, if you haven't yet, we would love some of your feedback. So zerotrustsgiven at gmail.com is where we're collecting all that feedback. Just please be kind.
Not saying that anybody has not been kind, but however, if you have any feedback around the show, we'd love to hear it as well as if you have a, if you have a question that you think is a good topic for one of the shows, if you could fire it in there and we read it on air, we'll send you a care package, a Zscaler care package. So that would be great. But again, so Tom Giannullos, my illustrious cohost.
Thank you much. Thank you. And Dan, thank you so much for coming in today.
[Dan Miller]
Thank you both.
[Tom Tittermary]
All right. Thank you much. We'll see you next time.