So What? Federal News Roundup on Zero Trust with Paul Puckett, Director of the Army’s Enterprise Cloud Management Agency

Carolyn:

Welcome to Tech Transforms, sponsored by Dynatrace. I'm Carolyn Ford. Each week, Mark Senell and I talk with top influencers to explore how the US government is harnessing the power of technology to solve complex challenges and improve our lives.

Hi, I'm Carolyn Ford. Thanks for joining us for So What? Tech Transforms' federal news roundup, where every month Tracy Bannon, senior principal with MITRE's advanced software innovation center joins me to co-host So What? And together, we unpack some of the biggest trending news topics in federal technology space. Hey Tracy. Good to see you.

Tracy:

Hey, how are you doing today, Carolyn?

Carolyn:

I'm doing great. I'm loving the pink, it's really popping. It always makes me happy to see you because you just look happy.

Tracy:

You just got to be authentic, peeps. You just got to be authentic.

Carolyn:

Yeah, it's always fantastic. Today we get to talk to Paul Puckett, director of enterprise cloud management office. Paul, did I get that title right?

Paul:

We've actually now become an agency, so we're now the Enterprise Cloud Management Agency, and that pivot happened just about a year and a half ago. We became officially a field operating agency and no longer a directorate within the CIOs, rather being in the CIO. I simply report to Dr. Raj Iyer as the CIO. And really what that did is it opened up our charter, so we moved from the typical policy and governance that you'd find with a directorate within the CIO, whereas now we definitely help contribute for policy and governance, but we are able to own the entire delivery of all capabilities and services when it comes to the cloud for the army. It allowed us to move into the realm of execution, which is something that we think is just absolutely critical when it comes to adopting cloud at scale.

Carolyn:

Interesting. I thought that that was your role before this reorg, that you had oversight overall of all of the army cloud before.

Paul:

Well, yeah, so there's... I'll unpack that word. If you look at the title of the organization prior, the Enterprise Cloud Management Office, it really denotes just the management, just the oversight of, maybe we'll say the guider, strategist, but more so other people are in the business of the actual execution and operations. And from a charter perspective, CIO is policy and governance only, but the secretary of the army at the time felt that there was a greater imperative and need for the ECMO to be more than just oversight, that we actually need to be truly in the services delivery business, actually delivering capabilities and services as a service to the army. More so than just the management of it, so while the management didn't change, we became an agency, and so with that pivot, allowed us to have a new charter that was created and ultimately approved by the secretary and by Congress. And so with that, it gives us the official authority to be in the business of the doing, rather than just the oversight.

Carolyn:

I love that, a doer and a... Seamer is the wrong word, what's the right word, Tracy? Strategist, but the doer, the implementer, that's fantastic.

Paul:

Yeah.

Tracy:

And it's a big move for government. It's happening in lots of different pockets in government, but it's a nice change to see, because government has been oversight. They've done a great job as oversight, but oversight without having that experience that Paul is bringing to the table, that his organization is bringing to the table, they can say firsthand, "This works," or, "We are continuously improving. Here's what we need to change." And it's not just book learning, it's not just having talked to somebody else. They're living it, they're doing it, and then they can better impact policy, quite frankly.

Carolyn:

Yeah, absolutely.

Paul:

comment, it's not [inaudible: 00:04:33

Carolyn:

Well. And I really like that you're a doer. Not that you weren't a doer before, but now officially, because we're going to talk about zero trust today. There's been a lot going on with zero trust, and zero trust has been around for decade plus, but there's been a lot of activity around it lately. Recent White House memo, and for me at least, it can be a very nebulous buzzword that doesn't mean a whole lot, even though I know we've all been told it's what we're going to do and we're going to do it by a certain timeframe. It would be really great if you could just level set us on zero trust, give us a definition that we can all digest.

Tracy:

Digestible definition please.

Carolyn:

Yes.

Paul:

Sure. I heard this from someone else, so it's not mine, I won't even claim it mine, but I just think it's beautiful. The journey of zero trust is continuously removing implicit trust over time, across all facets of your people, process and technology that delivers whatever mission, business, strategic objective your organization exists to achieve. And so to say that a different way, kind of the inverse is typically we have delivered capabilities and services, especially within such a highly regulated industry, such as the Department of Defense, where you having a certain thing or device or your presence predominantly within a network or within a security boundary of a network, like, hey, all of these things that I control that this system touches, I'm going to draw this artificial virtual box around, and so anything that finds itself inside this box, I can trust. It is implied trust simply because of your very being within that system.

And so this pivot and this move towards zero trust is there's a lot that is implied in the way that we've derived trust, where now it means that any adversary that all of a sudden happens to find themselves within that box next to us is just as trusted as anyone else or anything else. And that's quite frankly, that's the start of so many of the cybersecurity events that we see today, is someone rested their laurels on that virtual security boundary on that network, all of a sudden got owned and now came to realize their ability to see as well as remediate vulnerabilities within that boundary were just dramatically lacking. And so this journey of zero trust is to continuously over time remove implicit trust, and it's something where it is never done. We're always going to be seen and monitoring and finding-

Carolyn:

Exactly. Thank you.

Paul:

[inaudible: 00:08:51

Carolyn:

I think what you just said is very important to just repeat. Zero trust is something that's never going to be done. Is it fair enough to say it's a philosophy, it's an architecture, it's a living, breathing thing that... Is that... Yeah?

Paul:

Man, Trace, what do you think? It's more almost a practice.

Tracy:

[inaudible: 00:09:38

Carolyn:

Before we move off the definition of zero trust, because Paul's was almost like poetic, it was beautiful, but I need a story, Tracy. Give it to me in words that...

Tracy:

What do we say? Tech like I'm 10, or explain like I'm 5?

Carolyn:

Yes please.

Tracy:

All right, so look, if you think about it, the castle has a wall around it and a moat around it. If you can get into the castle, think about any of those fun movies, The Last Kingdom series. You get inside the castle, you pretty much can go anywhere that you want, right? No one's going to notice you. If you think somebody's going to notice your face, just pull your hood down a little bit and you just go anywhere you need.

Zero trust in this context means, well, we're not going to depend on the moat, we're not going to depend on the walls. Think of it now as going into a business and you have to swipe your key to go into the front door and you have to swipe your key to go into the next door, and you have to swipe your card key to go in anywhere, whether it's a bathroom, whether you want to pick something up, anything that you touch, anything that you want, anything that you need, we've got to prove that that's who you are and that you're allowed to be here and you're allowed to have access to that thing. That's the difference.

Carolyn:

Do you ever use the term continuous authorization with that? That's what it sounds like to me, but maybe I'm misusing that term.

Tracy:

It's a-

Paul:

[inaudible: 00:11:19

Tracy:

Go ahead, Paul.

Paul:

[inaudible: 00:11:22

Tracy:

[inaudible: 00:11:22

Carolyn:

[inaudible: 00:11:25

Tracy:

Let's just enter it right over here.

Paul:

Yeah, I think it would be best for us to just place that to the side for just a brief moment.

Carolyn:

Because that's a loaded term, right?

Paul:

Sure, it's a loaded term, but there are actually things that are implied in that, quite frankly. I would argue as we go on this journey, we need to constantly move across certain, I'll say steps within that framework. To use Trace's analogy like the moat and the kingdom... Well, let's be honest, we've all seen the movies. Typically, the king or the queen isn't just out there in the town square, just inside the moat. Typically, there are layers, like, whoa, wait, this is the King's quarters, which means that we've probably got some guards around that. There are probably other doors to be passed into. There's probably other credentials of who can actually go and meet with the king or the queen, and the reason being there is they said, "Hey, this person or this thing," think of the crown jewels, think of whatever it might be. "This holds value. This holds worth. If this were to be lost, if this were to be hurt or whatever it might be, we would find ourselves in just horrendous situations."

And quite frankly, if you look at the risk management framework, it's really no different. When we talk about categorization, selection, building an assessment ATO, any kind of discussion of a continuous ongoing authorization or continuous ATO, it requires us to constantly evaluate what is this thing of value? Therefore, what are the risks and the impacts and the probabilities? How do I therefore need to protect it in order for me to be able to go and execute my mission? And so really, if you think about it, this pivot into a zero trust architecture in the components, I think where people get lost is we say practice, and sometimes it's hard for people to wrap their hands around what to do next in a practice.

And so we'll create reference architectures, so we'll create new framework, so we start to put it into pieces so people can digest it. And I think just the simplest pieces, it really is requiring us to take an inventory of what we have, truly what it is, just how valuable it is, and then build the actual service and systems and capabilities to protect it appropriately, where there are no implied trust scenarios that we are just simply carrying it into the architecture for how we deliver it. Really, it just requires us to now know what we got, know how to secure it, no different than you would understand the king or the crown jewels, need some type of special access things, special credentials to it and a special place in which you put it that it's secure and you always know it to always be secure.

Tracy:

Right. And it's not as easy as just taking out a knight down the hallway and putting the hat on because you have to know that, right? You have to put on that uniform to get to the door. They've got to know the passcodes, you've got to know the protocols. There are a whole bunch of additional special things that you need in this brave new world where we are being more secure, and I love the phrase you used around those jewels, around things that are the most important to us. That also helps you, doesn't it, Paul, in trying to triage? You're an organization and you've got the memo. The memo says you've got 60 days to give me your plan, and now you have to start acting on this plan. I've seen a lot of panic where people are not quite sure where to start.

Carolyn:

Is this [inaudible: 00:15:18

Tracy:

From the time the memo came out, they gave agencies 60 days to have some sort of plan, just a plan. It didn't define what the plan is. It said 60 days to get a plan, and people ran towards the NIST reference architecture, they ran in different directions trying to figure out what they should do, but where I was going to go with this was to ask Paul some opinions on that risk profile. Not necessarily our map, but just taking a risk posture, knowing what's your inventory and trying to figure out, decide, well, what do I need to do first?

Well, what's your biggest risk? Well, it could be that massive lake where I put all my data in. It could be that thing. That might be a nice attack surface. Or it could be that I have a relatively open network because of where I sit or the type of people that are working with us, and when you sat through this as you've helped others, how did you help them over the last year as they've been panicking with this? How have you been guiding them on where to even start to think about this?

Paul:

cution order came out back in: 2019

Well, we were able to, the moment it came out, check that box, because we've had a cloud plan since we put this party together back in 2019, and put out the 2020 cloud plan just a few months after. But the taking inventory of what you have, and therefore how to protect it, is something that is going take a lot of time. For those that are trying to understand this, we say that data is a strategic asset, but... We're trying, but there's really no place, there's no database for anyone to go to query and understand precisely what data we have and what attributes we know about it. This doesn't exist. We're in the midst of creating it, but it's very immature at this time.

And then understanding truly how we need to enhance the actual protections of that data and the systems that are the mechanisms by which we are both creating as well as consuming that data, the attributes of those systems and how they have or have not been secured, sit within a system like EAMS, a relatively stale database of information that if you got your ATO three years ago, it may not have been updated for two and a half years. Truly being able to take that inventory of what do I have? What is this data? Has it been appropriately, one, classified, because we often see people over-classify data, but one, appropriately classified, and two, appropriately protected, that's just going to be something that people are going to do over a long period of time.

But how do we tackle this, one, from a technology perspective? How do we need to capture all these systems and all this data from a people perspective? What are the kinds of skill that we need? Because those people are going to be the ones helping us do that analysis and understand precisely where we are and where we need to be. And then from a process perspective, this can't take the same very, very, very long time that we've seen in how we've done assessments and accreditations before to enhance capabilities, let alone the process by which we need to start to deliver the specific technical components of a zero trust reference architecture when we talk about truly mature identity and credential access management.

That's not just an identity of a person, but really a persona, as a human can be an administrator, they can be an actual general user, they can be some other type of flavor of perhaps an empowered general user, much like someone who's able to contribute software code into a baseline, let alone your device now has an identity, if you will. Or even when we talk about machines working for us, there are identities that a machine now needs to have, to have machine-to-machine exchanges of data for a non-person entity.

There are all these things of maturity, and that's just ICAM alone, let alone the actual policies. If you have this credential and you're trying to access this data at this point in time in these contexts, then therefore yes you can, or no, you cannot, or only under these conditions. Both the policy as well as the enforcement of that policy has to now be universally understood across all of these systems, and then the attributes of data itself has to be universally understood across these systems. Otherwise, you can't exchange that data. And if you just pause on that, you've got a crazy amount of work to do.

Tracy:

We do.

Paul:

And so that I think is... That's a big elephant to start to chew, and thankfully in the army, and even discussions within JADC2, thankfully people have started to realize is that mature identity and credential access management really is that linchpin cornerstone from a technology perspective. Because at the end of the day, if you are going to move into explicit trust, we're like, "Yes, these two things can exchange this information. It means that they're going to be sharing the credentials by which they have been authorized to access data or exchange that information, and those credentials have to be universally understood." And so that, quite frankly, that first of what do you have that I also agree that we can now share this information, that ICAM maturity is really that linchpin and that's where the army, and really the DoD has been hyperfocusing now to start this journey.

Tracy:

I want to take us back to data and foot stomp on that a little bit. I talk about data as being our most important currency. It is the most important asset, it's the most important currency, and one of the things that I've observed and I've helped in good ways and helped in bad ways has been people want to consolidate their data. I jokingly say, "Look, you don't put all your money in a tin can in the yard because you don't need all of your data together. We have distributed compute, we will have distributed data." So our best bet, to your point, Paul, is where is my data, and in what state? When does it move and when does it need to move? And then branching out, who needs those accesses to it? Now, we've got tremendous duplication, triplication, quite right. We've got copies of copies of copies, so we've got a lot of challenges across all of government. Heck, across all of industry, but government is not unique in this situation. Some commercial areas just have been at this a little bit longer and have been forward leaning on some aspects of it.

That data, getting at that data, allowing that data to reside in place, not necessarily always moving it is hard for people because they've spent better part of two decades trying to get all their data in one place. How many efforts have been around, we've got to move this data forward, we need it all in one place for this reason? We've got technologies now, and not that tech is always the answer, but we do have better enabling technologies even now than we did five years ago, that help us with that data virtualization, with those semantic layers, with data fabric. We can get into long discourse over data mesh and then into dynamic policy. Policy is code, and how do I make that policy as code? How do I connect that to my ICAM, my identity management to get more full bodied? Now, those are all nice words. Building that is difficult, knowing how to map it.

What I am fearful of, love to hear your thoughts on this, I'm fearful that people are going to try and design the Taj Mahal, and what they really need to do is get started with some of this experimentation for their organizations. Don't draw a huge map, draw a small map. Get started somewhere so that you get, to your point earlier, get people's hands on. Get them used to your organization needs to get smart, and the only way that your organization is going to get smart is not simply by studying it, it's going to be by doing some aspects of it. And they're going to fail and they're going to fall down and that's okay, that's great. They're going to learn as long, as they're learning using hypothesis-driven approach to this, we think this, we're going to try this, this is what we learned. We didn't succeed or fail, we have an outcome. What are we going to do with that outcome? Well, we need to do a better job of X or of Y or of Z.

Carolyn:

Haven't a lot of agencies already started at least some pieces? Paul, have you-

Paul:

Oh, for sure. Yeah.

Tracy:

Oh yeah.

Paul:

ed at maturity. It [inaudible: 00:25:44

Tracy:

e a maturity model [inaudible: 00:25:47

Paul:

they have or even [inaudible: 00:26:45

Tracy:

Well, how are you finding... How are you mapping at all? Do you partner with industry to do it? How are you tracking it?

Paul:

Yeah, so it starts in a few different ways, and I'll take it this way. First you need to start to deliver an actual catalog. When people come to the table and they say, "Hey, let me tell you within this system that I have, that I'm a system owner, let me tell you all the data fields that I've got, the dictionaries that help you understand by which what I mean by this thing." In a field of a database that says F underscore name, it means first name, and that would mean the same thing as somebody else saying the word just first name. When you see F name and first name, it actually is trying to tell you the same information, because it's talking about humans first name. That catalog of data has to be centralized, and so the army has got the enterprise data services catalog, which exists for precisely that purpose.

And that's really where we're starting, and we've actually been started for quite some time, but there's so much work that has to move beyond that, and I'll hit this from a pains perspective. When I first came on board to stand up the ECMO at the time, a lot of people would say, "Hey, the cloud is insecure and it's not secure enough for my data." When in reality, the examples that they would draw were systems designed that actually had no idea what data that they had, and they were designed in this build a big moat and it's the biggest moat in the world and everything's great perspective. Then they found that someone actually breached their moat and got access to their data, and now of a sudden the data in the system in the cloud is insecure, when in reality, as part of that move into a new infrastructure environment, they should have done the work to understand, ooh, what data do I actually have, and am I protecting it appropriately and is truly taking that inventory?

And I would say a lot of people haven't done that work, and therefore it's whats continuing to seed these feelings of insecurity, and it's a false sense of security because people, when they say, "Oh, I'm not going to put it in the cloud, I'm going to keep it on-prem," the point being is your on-prem infrastructure is just another big moat that you hope no one ever breaches if you're not doing that hard work. That's why I say the data engineering side is so critical for us to first take an inventory of what we have and then be able to drive, okay, here's how I need to appropriately protect that data that starts to fall into this more zero trust architecture as I remove implicit trust over time. Does that start to make sense, Carolyn?

Carolyn:

Yeah, I'm just thinking about my spice cupboard. I can't even take an inventory of it, so I'm thinking about all this massive data that you're talking about. It sounds overwhelming and impossible to take an inventory and to keep that inventory up to date, so how do you do that?

Paul:

You're right.

Tracy:

Well, you're also incentivizing different folks in different ways. In Paul's analogy and merging that with yours, Carolyn, imagine that we don't need to index everybody's spice cabinets in town all at once. We need to start with one of them, and so Carolyn's going to start with her spice cabinet and she's going to be incentivized, and we have to talk about that, what will incentivize people to actually give that information away.

Carolyn:

And it's a manual process.

Tracy:

It's not all manual, but there are aspects of it that are human-intensive. There are absolutely tools that you can run against your data that can crawl, that can create your... Gosh, it can give you duplication issues, it can give you conflict issues, it can give you all your schematics, it can show you where you have across your own enterprise, duplication, triplication, it can show you all of that stuff. The tools are just that, though. They're tools, they have to be leveraged by smart people. Bit of a question for Paul. How do we incentivize folks to want to contribute? Because I'm also seeing two things. One, I'm seeing people say, "My imperative is that I'm doing this bit of work and I don't owe you anything, therefore I'm not joining in that club. I'm just not joining in that club." The second one is we've got, getting into that data hoarding and incentivizing folks to share, it's a carrot and stick. What's the carrot? I know what the stick is, it's policy, it's funding. What's the carrot in all of this, Paul?

Paul:

Yeah. Okay. Tell a quick little story. 9/11 Commission happens, and what was their finding? Their finding was the different agencies within the intelligence community actually had all of the data that would help us potentially avoid the catastrophes that happened on 9/11, but because of this culture in, not necessarily data hoarding, but it's this feeling as though there's a sensitivity to my data and no one can get access to it. When in reality, even you and your own people getting access to it is a who you are and what you have and what you should need to know type of thing. It is at the very least, we need to share with each other What those parameters are. Doesn't necessarily mean that everyone has access to all the data willy-nilly. No, it just simply means that we're sharing in, I'll say the calculus, if you will, of the if this then that of where all of those attributes are met, you can appropriately have access to that data.

Putting that in a place that was discoverable, and one of the core components that came out of the 9/11 Commission, and now the immense data maturity that you see in the intelligence community was also them aligning on centralized identity and credential and access management. What is the actual policies and then enforcements for the credentials presented for the attributes of data? And the big push that you saw with, not to be confused with other gov clouds, but NSA gov cloud was creating the actual metadata catalog for everyone to start to publish and populate simply the attributes and the access controls of the data that they had, not necessarily the data itself, which meant that people can go and get access to it. I think from a carrot perspective, quite frankly, it's the mission imperative, comment one. Comment two, and I wouldn't necessarily call it a stick, but I struggle maybe to call it a carrot, is we cannot predict the future.

We oftentimes we'll go and acquire and build new systems and say, "Hey, this system has to be able to talk to these five other systems," and we create these very custom point to point interfaces to talk to those five systems. And all of a sudden something happens and we're like, "Oh, my gosh, there's another system you're supposed to be talking to, and I've never thought about it." And quite frankly, rather than trying to predict all the systems you have to talk to and write a whole bunch of custom code to do it, we really just need to say, "Hey, you're going to be creating data, you need to be able to publish that data to be discoverable by others, and you need to have interfaces built to open commercial standards so that if they meet all these wonderful attributes, they can go and call and get access to that data."

e come from DevSec [inaudible: 00:34:45

The second one was common tools and services for modern software development, because if there are some common things that we probably need access to, like a code repository or build pipelines, or some type of security or testing scanning tools, rather than have everyone go and deliver the same thing 50,000 different times, we probably deliver it once and have it be consumed by many. But the third key component that we pitched was common data services, so we said, "Hey, is it manual?" A lot of it could be automated, like Trace said, but it means someone's got to be in the business of delivering those tools and those services for people to consume, otherwise you're going to get 1,000 different data exact trans... Transform and load or load transform, choose whatever flavor you want, as a service, and they're probably all going to do it just a little bit differently.

And that third piece I would argue is the most critical piece, and I would also argue it's probably the most immature piece that we see in the DoD today. A lot of the data services that we see stood up have been data services around specific data domains, like, hey, you deal with cyber monitoring sensor data. Cool. Here's your data ecosystem for you. Oh, you deal with personnel data? Cool. Here's your data ecosystem for you. But if you don't purposely fit into those buckets, you're left paying and saying, "Who can help me with data services?" And so we started to lean in there to deliver an API management platform for both the creation, the publishing, and discovery of now these new open interfaces that aligns to the data decrees.

And we see that as really step one in the common data services business. We're starting to see more and more entities in the army realize, hey, this isn't something that needs to be hoarded by any specific data domain. These common data services need to be common to all, and much like the data services catalog and the API management platform, we need to start to expose these services, because that hard work of what data do you have and the things that can be automated, need to be automated. Where do you go to consume those services, to understand and now be able to categorize your data appropriately, so then we can focus on how we appropriately secure it and create the access policies around it.

Tracy:

I want to give a compliment that I didn't realize until this moment, specifically that the types of things that you're providing, the types of things that ECMA is doing right now has really... It's been a mindset shift, right? Because it is, you're an enabler, you are providing, you're treating every PEO, every program, anybody who reaches out, you're sensing what are the things that they're going to need, and you're rationalizing, how can we provide this at enterprise scale, enterprise class? How can we provide the education? How can we provide the jump starts, the SDKs across the software capability, as you said, across the basic cloud aspects and across the data services? Kudos for thinking like a service provider, kudos for not coming at this with the traditional dogma, the traditional DODAF, TOGAF, thou shalts in a way that made people... It got in their way as opposed to help them. It disabled instead of enabled, and so some of the approaches that you're taking right now specifically are enabling without disabling, and so kudos, Paul. Really appreciate that.

Paul:

I appreciate that. It's definitely a team effort, but one of the things that I've been really adamant about from the beginning, and that's that whole carrot-stick discussion, is there's no commercial company in the world that is mandated to be used by all their customers. They're in the business of how do I actually capture a market? How do I deliver a service and capability people love using? And when we first stood up the ECMO, we started delivering services, very adamant to the team. Like, hey, listen, no one's going to be consuming our services because of some mandate. That's just simply a world that creates shadow IT. We have to first capture people and deliver services that they love using because we add value, and therefore that means we need to be really purposeful as to where we spend our time, because we have limited resources.

ng services within [inaudible: 00:40:55

Or does it make sense for you to do your own thing? I'll just grab a lot of the services we do in ECMA is like the Walmart. You've got a number of people that are like, "It's winter time and I'm cold and I want to be warm, but I also want to look amazing while I'm doing it." It's like, "Well, calm down." More than likely, the most important thing is you're just warm with that 80%-

Tracy:

Let's prioritize.

Paul:

Right, it's prioritizing. Not everyone needs a Gucci jacket to look amazing, but sometimes there's some special scenarios in those cases, but let's address those edge cases truly as edge cases. So that's-

Carolyn:

As you...

Paul:

Sorry, go ahead.

Carolyn:

As you implement the services that everybody loves and wants to use, which, what a great mindset, assuming you are building them with zero trust in mind and using that practice, or you add zero trust in later, how does it affect the end user?

Paul:

Yeah, so there's a few different ways around this. Something so elegantly done, the user should be unaware. However, there is a people upscaling thing here that needs to be done, no different than the world in your personal email account that you use at home, starting to employ two-factor authentication, other mechanisms that starts to ensure that you are who you say you are, the credentials you bring are truly your credentials, having that, hey, I'm going to just ping and send a little code to this device that has been registered that I understand. You've seen those things like, hey, should you trust this device for a period of time?

What's really happening there is you're saying, "All right, is there a token that this device is going to be given as a credential that says, "Hey, this thing is cool for the next 10 minutes or 15 minutes." Whatever it might be. You're actually really the recipient of someone who is starting to enhance the maturity and the capability of their services, and it shouldn't feel so dramatically toilsome where at the end of the day, the value is you actually getting access to your email. If it's so secure that you can't even get access to your email, it's kind of a problem, and so-

Tracy:

Well, that's a conversation for another day, Paul.

Paul:

Yeah, for sure, but that's oftentimes how the DoD has implemented policy. It's why we see Michael's thing out there of like, "Hey, fix our computers." We've imposed so much overhead on these systems that they're not usable, and that's why the actual user center, the user experience executive order that came out, that got me jazzed because it creates these bounds in the sense of, hey, all these things at the expense of the actual user experience cannot be the way that we do business. And so there's a little bit of tweak to that, so for how we deliver services, I think so much of zero trust is in thoughtful architecture, which we have been quite purposeful in how we deliver services. But we're also customers of other services that exist in the army, so for instance, the army is not the ICAM service provider for the army. We're consumers of that.

But how are we able to influence their backlog and their prioritization and their way forward? Part of the new RDP that came out for the army's ICAM strategy, very close relationship between myself and General Stanton over in the Cyber Center Of Excellence and the actual drafting of that to create the structure and the objectives to be achieved with a mature ICAM solution that addresses not just humans, but also nonperson entities, devices that also addresses both the enterprise and the tactical domains. And so we've got influence there that then helps, and quite frankly, grows the community of doers that see this new imperative in how we need to be delivering services. It's not just the ECMA and C-army, it's really collective trying to get after the components of a zero trust reference architecture.

Tracy:

I want to summarize what I just heard you saying. To Carolyn's question, what's this mean to the end user, there are three different things that are going on there. One of them is, to the extent possible, it'll be invisible. To the extent possible, but it's not always going to be invisible, so there's upskilling. There's upskilling so that they know what MFA is, and they also have a shared sense of responsibility because security, cybersecurity, cybers is everybody's responsibility. And the third thing that I heard Paul say is they actually have a voice. They have a say in this, so they are consumers of all of this, so they need to be able... Folks need to have that openness, that psychological safety, they need to be able to raise their hand and say, "That ain't going to work, and here's why. At least hear me and help me work through this." And that's a bit different than what we've seen in past decades. It's a nice place to be right now. That means that there's user centricity going on, that we are becoming human-centered with what we're doing.

Carolyn:

Yeah, that was a really great summary.

Paul:

[inaudible: 00:46:17

Carolyn:

Paul, when you were talking, what I heard was zero trust is going to make my life easier, to be honest. Because if you guys do it right on the back end, then my life should be easier even with MFA, and if there's something that's not working for me, I can say something, no?

Paul:

Well, so I'll say yes and. There's a few layers to that, Trace.

Tracy:

Yes and. Yes and. [inaudible: 00:46:48

Paul:

[inaudible: 00:46:48

And so it's created, and even still today, and this is place for a maturity, it's created a world where, well, then therefore, everything about 365 has to be built to a specification for Impact Level 5. That is not just unclassified data, not just controlled unclassified data, but also unclassified national security system data, NSS data that has to be to the tightest security controls possible. But in reality, there's no metadata catalog of all the data in 365 where you can say, "This is Impact Level 4, and this is Impact Level 2, and this is Impact Level 5." It doesn't exist. You're going to see coming is for when you start to create emails, it's going to say, "Hey, that email that you're trying to send, can you just classify it for me real fast?" Is it Impact Level 2, is that Impact Level 4? And that requires people who trained-

Carolyn:

I'm going to get a message... Well, it's not different than...

Tracy:

Think about it right now, when you send an email, especially if using Outlook, it'll say, "Did you forget to attach something?"

Carolyn:

Yeah, [inaudible: 00:48:39

Tracy:

Because in your body of it, you said, "I've got this really cool file, or here's a picture." It's reading that and it's interpreting that, right? This is simple algorithms. You're going to see more of those algorithms, to Paul's, point as being fed as the data, the metadata is captured about it, and then they're able to look at the information inside that email. Hopefully that will also make life easier, because you can have less of these rigid controls in place that lock things down so much, and you're becoming dependent upon those prompts and those users to say, "Yes, I have classified it the right way. I have tagged it."

Carolyn:

I like those prompts, especially when they say, "It's after hours for Carolyn. Maybe consider sending this email tomorrow."

Paul:

I would now encourage you to put down the work computer and recharge, but it's things like that. There are of course, natural language processing that can look at your emails and start to help classify and categorize that for you, but part of building those algorithms and maturing those algorithms over time is to have input from humans, no different than when you do a caption online, and you say, "Here are all the sidewalk pictures, or lights that's in the thing." There is an onus on a user where we need the user to help contribute back into the ecosystem, but from your point of like, yes, it's intended to make your life easier, because for instance, the fact that we often over classify data means that now when we want to get into data sharing, there are crazy amounts of steps with humans we have to go through to reclassify that data that never should have been seen as some higher classification, just in order to share it is, if that's classified at its moment of creation, now you want to be able to share it, and it's perfectly shareable. You can start to do that.

Yes, it should make your life easier, but it also should make our outcomes more repeatable and are-

Tracy:

[inaudible: 00:50:31

Paul:

Exactly, make us more efficient at the way that we do business so that...

Tracy:

And secure. More secure.

Paul:

There's a number of pieces. Well, naturally, if you know what you have and you can protect it appropriately, naturally, the byproduct of that is security, but you made one comment that I want to wrap to that, is security postures are constantly changing over time. New vulnerabilities are coming out. New zero days exist, which means that every single system in service that we build and its acquisition strategy around it, the contract for it, the tools and the mechanisms we give to those teams really never goes into sustain it. It never goes into operations and maintenance. It is always in some form of continuous enhancement, whether that feedback loop is a security vulnerability or a user, and I would argue historically, there has been no shortage of people expressing their pain in using the system. But oftentimes we never created a contract or put somebody in charge whose job it was to listen, to prioritize and to address those user pains.

Carolyn:

And now we have.

Paul:

Well, that's this intention of the components of agile acquisition and agile software delivery practices and human-centered design, and leveraging continuous integration and delivery pipelines where we start to automate and orchestrate all of the security and operational development with testing processes that have typically taken months, if not years, to go through are now becoming more of an automated non-event. Which means that I can listen to your feedback, do something about it and have a solution out there. Each one of the services and capabilities that the ECMA has put in place, we have designed our contracts precisely for that mission, because the world is constantly changing, which means that we need to constantly adapt with it. And so our ability to mature in a zero trust practice requires all of the services and capabilities that we have to be able to respond to security events as well as user feedback so that we can continuously remove implicit trust over time.

Tracy:

This gets us... We're going to start hour two, and we're going to go into... I'm going to keep talking at you Paul. I'm going to keep talking to you.

Carolyn:

I was just going to say, Tracy, you got to pick, I'm looking at all my questions. I'm like, "I need Paul for a few more hours."

Tracy:

No, no. We don't. What we need to do is we need to wrap because I think people have a lot to digest with just this. They're thinking about data, they are thinking about that moat concept, they're thinking about prioritization. They're thinking about, do I have an ECMA in my neck of the woods? If I'm not working with army, who's my ECMA? Do I have an ECMA, and if I don't, who should I be leaning on? Who should I be looking to? There's lots of stuff here to chew on.

Carolyn:

up on our wall and [inaudible: 00:53:49

Paul:

read the... This February of: 2020

Carolyn:

Our lives would be easier and better if we could just do those three things.

Paul:

ms, especially the [inaudible: 00:54:29

Tracy:

And the buzzwords are everywhere. Part of why we're doing this podcast series is to take people past the buzzwords, but not get into that deep dive. People are not going to walk away from here and immediately start implementing, but they're going to be noodling on this stuff, and that's the most important piece, Paul, so... Oh, I really want to thank you for joining us today. This has been a fantastic conversation, and Paul, I also, truth be told, am getting to work with Paul here and there with some of my work with the army recently, so I'm getting to see both sides of this, as the observer from the outside and a little bit on the inside. I'll shoot you some feedback on what's going right and what's going wrong there, Paul. Just joking, just joking.

Paul:

No, it's been great working with you, Trace.

Tracy:

I appreciate it. Carolyn, where do we go from here?

Carolyn:

Well, I think you just said it. Thank you Paul, for joining us. And I feel like I have more clarity around zero trust being manageable, even though you... We talked about these huge elephants, but there's a methodology and there's a way to approach and attack this, and you guys are doing it, so thank you so much for taking time to talk to us today. And to our listeners, thanks for listening, and I'm sure this will be a widely shared podcast, but be sure to share, like, and we'll talk to you next month. Thanks for joining Tech Transforms, sponsored by Dynatrace. For more Tech Transforms, follow us on LinkedIn, Twitter and Instagram.