A man in a black suit and black tie was sitting at the conference room table in the briefing center with his hands steepled. The Zero Trust team was gathered around the table, and Brent was standing at the video wall in front of a picture of the MarchFit data center.

“Bob clearly is a rogue insider, but he was more than that; he was a ronin. A ninja,” Brent said, gesturing to the ceiling tiles along the row of cabinets. “He must have trained all his life in both ninjutsu and the dark arts of hacking. He would have had to sneak into the data center through the air ducts, then descend down through the vents and put the USB drive hidden inside his katana into the server.”

“Bob is a terrible name for a ninja,” Harmony observed.

“No one would expect a ninja named Bob,” Brent agreed. “Which is what makes it the perfect name for a ninja.”

The man in the black suit spoke up. “That's cute. Would you like to make it interesting?”

“Sure, wise guy,” Brent said.

“How about a coffee?” the suit responded.

Brent looked at the coffee machine in the lobby of the briefing center and shrugged. “Deal. What's your theory?”

The man in the black suit stood up, went to the video wall, and pulled up a picture of Bob. “Bob Paulson was one of the original employees of MarchFit. His stock had finally vested, and he left the company voluntarily over the summer to move to another startup. He would have had a lot to lose from the company experiencing a breach, but that by itself doesn't mean he didn't do it.” A smug grin went over Brent's face at this, but the suit continued.

“What we do know for sure was that somehow, Bob's account was used to access the source code repository for the treadmills, which is weird, because he left the company several months ago and you would have expected that his account would have been terminated by the identity management system.”

“Hey, Brent, aren't you on the identity team?” Rose asked sweetly. He had folded his arms and was staring back at her.

“It turns out that Bob wasn't just a developer at MarchFit; he was also a client. We know for sure that, although he could still be a ninja, Bob wasn't in the data center at the time because he was running on his treadmill about 1,200 miles from here.”

“Why wasn't his access revoked like normal?” Dylan asked.

“Our understanding is that MarchFit's identity management system only has one domain that mixes customer and employee data in the same place. So although the process to terminate access was triggered, it failed because he was an active customer. He retained all the same permissions that he had while he was an employee. When he clicked a phishing email last month, the cybercriminal was able to get access. And since Bob was working out at the time, when he got the two-factor request to his phone, he thought it was legitimate and approved the access. Brent, I'll take a cappuccino with two sugars. Thanks.”

“How do you know?” Brent asked.

“Oh, didn't you realize? He's the FBI agent in charge of our case.” Dylan laughed. “This is Agent Paul Smecker. Noor asked him to debrief us on the current status of the investigation since she thought it might help us focus our efforts.”

Nigel patted Brent on the back as he headed toward to the coffee machine in the other room.

“Perfect timing actually,” Aaron said. “Okay, it's never a good time to have a compromised account, but identity was the next protect surface that we needed to work on. Identity is one of the most important parts of Zero Trust. Zero Trust consumes identity to help ensure least privilege. But identity is also one of your most important protect surfaces, so you need to protect it just as well as your other critical assets. I would actually argue that while your ERP is your crown, the jewels are the people. Who remembers the first Zero Trust design principle?”

“Understand the business,” Rose replied.

“How does identity impact the business?” Aaron asked.

“Knowing who your customers are allows you to create a more personalized experience that better meets their needs,” Rose said. “We retain our customers longer than our competitors, and our personalized experience means we give more of what we want to our audience.”

“It also allows you to build security into the product,” Aaron added. “The protect surface in this case isn't just one identity domain, however. It's two. There's this old saying: Hackers want access, and your employees have it. When you look at the Lockheed Martin Cyber Kill Chain, identity is the single biggest target. In the reconnaissance phase, cybercriminals will exhaustively research your employees and send mass phishing attempts to validate which ones are active and attempt to read their email to get even more insight into how your organization works. In the infiltration phase, they will attempt to spear phish IT admins or executives and attempt to move laterally to discover what assets their stolen credentials will get them. In the exploitation phase, they might attempt to brute force domain admin accounts from within your network, make fake account requests, or potentially create their own accounts if they've compromised the directory.”

“It's a dirty job, but someone has to do it,” Brent said.

“In the spirit of limiting the blast radius of an attack,” Aaron continued, “the first thing that we'll need to do is to create separate identity domains for customers and employees. These two areas should never overlap.”

“I've been saying this for years,” Brent said walking back in, coffee cup in hand. “We've always been told it would be too expensive to make the change.”

“We've already begun forcing all our users to change their passwords after the hacker's tweet,” Isabelle said. “Sixty percent of our users have already made the change. Will this mean we have to make them change their passwords again?”

“Instead of moving your customers out of the domain you already have and creating a new one for them, we'll create a fresh domain for employees,” Aaron said. “We'll do this for several reasons. Consumers are reluctant to accept any changes to their service, so there's less risk this way. At the same time, we'll want to increase security protections for our employees. And, of course, we'll be ensuring that all former employee accounts are removed.”

“Brent, I think I'll need your help capturing this for a project request,” Isabelle said. Brent stood behind Isabelle as she began creating a project charter.

“While they work on the project request, let's talk about the next step in the process: mapping transaction flows,” Aaron said, pulling up another diagram into the video wall. “Usually this part can take up to a year to flesh out all of the ways data is being used in your environment. Fortunately for us, the hard work has already been done because of your GDPR data mapping project that was completed last year.” Aaron displayed a spreadsheet with hundreds of rows of data flows through the organization and which roles in the organization have access to that data.

Isabelle leaned over to Dylan. “GDPR is that new European privacy law,” she said proudly.

“How does this help us?” Harmony asked Aaron.

“The goal of identity is to ensure uniqueness of every human or nonhuman in our environment,” Brent said, looking up from Isabelle's computer. “The best way to ensure we're employing least privilege across all our systems is to start with the data, what services are connected to the data, and then decide who needs access to it. Right, Aaron?”

“That's surprisingly on point, Brent,” Aaron observed. “And since we'll be starting over with our employee accounts, we should also address the process for provisioning new accounts. Since we're setting up a new identity domain, we also have an opportunity to provide more secure authentication methods for employees. We can require granular authentication methods per user or role. But we also need to require users to register multiple authentication methods. When an authentication method is not available for a user, they can choose to authenticate with another method. We'll always require password, security questions, and email address, but we can also choose an app on their smartphone like Google or Microsoft Authenticator, OATH hardware tokens, SMS, voice calling, or application passwords.”

“Ideally,” Brent added, “we wouldn't use SMS or voice calls for employees since we know calls can be intercepted or phones can be cloned using SIM-jacking.”

“What's SIM-jacking?” Rose asked.

“It's where a criminal calls your cell phone carrier pretending to be you,” Brent explained. “They'll say you got a new phone, and then start getting all your text messages sent to their burner phone. Most people won't notice anything's wrong until they need to make a phone call and their cell service no longer works.”

“SMS is probably fine for consumer applications. But the idea is to consider all the ways that authentication can fail before the failure happens,” Aaron said. “And while we're talking about the provisioning process, we should also plan for the deprovisioning process.”

“You mean when someone gets fired?” Harmony asked.

“Well, yes, although most employees leave voluntarily. But we'll also need to make sure that when someone changes jobs within the company, they don't retain access that is no longer needed,” Aaron said. “How do you get your users their account information and set passwords? How do you set up your password challenge questions? How do you enroll users in MFA?”

Brent considered this for a moment. “Initially, HR will process the paperwork for a new hire. We'll send them login instructions to their personal email, and then send a one-time password to their cell phone. It's not 100 percent secure, but it is using separate channels. After that they have to change their password. They have to enroll in MFA at the same time.”

“This will be one of the areas where we have an opportunity to remove trust,” Aaron said. “How do we know that the new employee's personal email account hasn't been compromised? We don't. So when we build the account claiming process, we can ask the users to validate their identity by asking them to answer three or four questions that they would have provided during the hiring process.”

“Isn't this a productivity issue?” Rose asked. “I mean, with the pandemic and all, I've heard some employees may be paid for weeks with nothing to do while they wait for their permissions to get assigned. Some supervisors have said they share their passwords with employees just so they can get the work done.”

“That will be one of the biggest goals with Project Zero Trust,” Aaron said. “We'll need to be able to make sure that any identity has the right permissions at the right time and with the right context. We'll need to implement automated feeds from the HR system to assign permissions at least daily, but maybe even hourly. This will help us react to changes to the identity life cycle in near real time and will help strengthen our security posture. And in real life, humans use other humans to delegate or proxy access to. Identity needs to help with this. The president needs to delegate access and authority to his vice president when he's on vacation, for example.”

“Does this mean we've already started architecting the environment?” Harmony asked.

“You're right,” Aaron said. “Now that we're talking about how we go about creating identities, we've entered into the third step of the Zero Trust methodology. We know that the third step is to architect your Zero Trust environment, but I want to make sure you are prepared to do this part on your own since it's easy to get confused when you come to a new protect surface and you're not sure how to apply the methodology. What principles do you follow when you do Zero Trust architecture?”

“We focus on eliminating trust,” Dylan said.

“Exactly,” Aaron responded. “When we looked at firewall rules, we got rid of rules based on IP addresses because the bad guys are great at finding those and exploiting them to get full access to a server, for example. We installed next-gen antivirus because we don't trust applications and we don't give users local admin rights because we know that attackers will install malware that way. When we look at safelist files or applications, we got rid of those because the bad guys are experts at detecting those exceptions and using them like a Trojan horse to install malware.”

“Trust is a vulnerability,” Brent said.

“Right again,” Aaron continued. “When we look at our most critical systems, we know that we have blind spots. Sometimes we need tools to help us detect those blind spots and often we need to lean on our business partners to help us have an attitudinal perspective that can overcome blind spots in the future.”

“So what does this have to do with identity?” Harmony asked.

“Identity is one of those highly technical areas where it's easy to get lost in the details and lose sight of the big picture. With identity, we have built-in blind spots. It's easy to think of my digital identity as an extension of myself. But it's not like the movie Tron where there are little people inside a computer hanging out with each other and having conversations. Were the people in The Matrix really in the matrix? Of course not, there are no humans in computer networks. While we may use identities to uniquely identify our users, those identities aren't our users. Therefore, as we architect our Zero Trust protect surface for identities, we shouldn't trust identities.”

“So it's like the woman in the red dress,” Brent said.

“I don't get it,” Rose admitted.

“That was Neo's final lesson in The Matrix,” Brent explained. “He wasn't really in The Matrix at that point. In a way, that was like a man-in-the-middle attack.”

“Wait, how do we do identity if we don't trust identity?” Harmony asked.

“We have to start at the beginning of the identity life cycle and look for opportunities to remove trust from the equation. For customers, this might mean adding an ‘I'm not a robot’ button to ensure that it isn't a bot enrolling in the service. For employees or contractors, there may be a different process to start the provisioning process. And whenever we think about provisioning,” Aaron said, “we have to consider deprovisioning at the same time. Even if a team member is just changing jobs inside MarchFit, we still need to make sure their permissions don't just keep ballooning bigger and bigger over time. And like we saw with Bob, there are a lot of security risks with orphaned accounts. Isabelle, as we create the charter for the new employee identity domain, we'll need to ensure that we're including automated provisioning and deprovisioning of accounts with the help of adjacent and applicable business processes. Automating this process will allow us to get the full value out of our identity system by reducing the number of manual access changes, reducing the potential for error or outright fraud.”

“How granular do we need to be with provisioning access for Zero Trust?” Brent asked. “Normally we grant permission based on user roles, but we could always have more customized permissions.”

“Remember, the goal of Zero Trust is to prevent breaches. But with identity, there is a balancing act that we have to do. It's true that more customization can provide more security, but it also makes it harder to automate and thus introduces more room for error. I think you're right to bring this up now, since as the company has grown, more and more roles became separate, so a role cleanup is probably in order at this point. Isabelle, please add that to the project charter as well.”

“I'm getting the impression that the identity project is going to be the longest part of Project Zero Trust,” Dylan said.

“In some organizations, a Zero Trust initiative can take two to three years,” Aaron admitted. “But you've got a lot of the key elements already in place. The GDPR assessment, for example, probably took about a year off that time frame. Identity will consume a lot of hours, but it can also be done in parallel with the other areas that we'll work on. So we'll still be able to make our six-month goal for the project.”

“What other things do we need to consider when it comes to identity?” Rose asked.

“What about Single Sign On?” Dylan asked.

“We've already rolled out SSO to several of our major applications,” Brent said. “But the various parts of the organization have over two hundred different unique services that we support, some with unique logins that aren't even a part of our identity system. MFA is already integrated with SSO. As a part of the conversion to the new IAM domain for employees, if we required SSO for all our applications we could speed up the adoption of both SSO and MFA.”

“You can also use something like a WAF on your SSO page to help detect credential stuffing attacks where cybercriminals have stolen usernames and passwords on other sites and try to use them on yours,” Agent Smecker said. “Unfortunately, this works very often since users don't use unique passwords on all the sites they use.”

“Brent, are you using any federation in your identity system?” Aaron asked.

“Not today,” Brent said. “But I see where you're going with that. If we move our employees to a new domain, that would allow us to give our customers the option to bring their own identity from their email provider or social media site. We couldn't let that happen with our employees, so we've always been anti-federation.”

“Like the Klingons,” Harmony joked. After no one laughed she said, “What, a room full of nerds and no Trekkies? Ugh.” She pulled her hoodie over her head and resumed typing.

Isabelle lowered the screen on her laptop. “Is that all there is for the identity project?”

“There are still a couple things we'll need to talk about,” Aaron answered. “Brent, what are you doing for PAM?”

“Who's Pam?” Rose asked.

“We don't have a PAM system yet,” Brent admitted.

“OK, what's PAM?” Rose asked.

Brent leaned back in his seat. “Privileged access management is used to manage the superuser accounts that IT administrators use to control servers and other systems. These should be kept separate from their normal, everyday accounts that they use for email. Admin-level accounts are one of the primary targets for cybercriminals, so having a system to manage them more closely is critical. A PAM system can rotate passwords for admin accounts much more frequently than a normal account, and audit controls can be configured much more tightly. I always thought PAM was cool, but we've always been too busy with product releases and testing to get much traction there.”

“What do we do today?” Dylan asked.

“Oh, we do have separate email accounts and admin accounts for all IT staff. They use their admin account to perform any administrative tasks, and that account doesn't have an email associated with it. But there are also PAM tools for admins to have a temp login, and that can be another project that gets spun up.”

“That's good,” Aaron said. “They can do a lot with just a normal employee account. But like we saw with Bob the cyber ninja, they can do almost anything with an admin account.”

“I thought MFA was supposed to fix all that,” Harmony said.

Brent sat up again. “MFA ensures that the user making the authentication request is who they say they are, because the user must input an additional token that is generated on another device they own. The secondary factors used in MFA policies are much more difficult to spoof because they are time-sensitive and generally tied to hardware that an attacker is less likely to get their hands on. But it's not impossible. I guess sometimes users do click the second-factor request even when they shouldn't.”

“How does failure work with MFA?” Aaron asked. “What happens if a user has a lost or stolen phone? Or what if they get a new device?”

“We ask them to save a backup code or call the help desk,” Brent said.

“Wait, how are they supposed to call the help desk if they don't have a phone?” Harmony asked. “Or what if they saved their backup code on their phone?”

“Well, they can always just reset their password and re-enroll their new phone once they get it,” Brent said.

“But they can't work in the meantime,” Rose said.

“This is another great opportunity to remove trust from the identity process. One of the most common ways attackers compromise accounts is through resetting a user's password. Usually, the challenge questions we ask are easily guessable. I actually recommend that we require an MFA reauthentication before a user can change a password to ensure they are the one making the request.”

“Why don't we just require MFA everywhere and force everyone to reauthenticate hourly,” Nigel said. “Wouldn't that fix everything?”

“Unfortunately, no,” Aaron answered. “Agent Smecker, can you talk about the ways that cybercriminals get around MFA?”

“Sure,” Agent Smecker began. “Let's say this cyber ninja, Bob, needs to break into an organization. Since Bob is a ninja, we can assume he's already compromised the username and password. Bob has three ways to deal with MFA. He can disable or weaken MFA. He can directly bypass MFA. Or he can exploit an existing exception to MFA.”

“Wait, I thought multifactor authentication was supposed to be secure?” Harmony asked.

“It certainly raises the degree of difficulty,” Agent Smecker answered, and took another sip of his cappuccino. “But like Brent said, this guy is probably a ninja. To disable or weaken MFA, he might choose to modify some trusted IP address configurations inside MarchFit, for example. Or if he wanted to bypass MFA altogether, he can use SMS intercepts like you've already mentioned. Or he could compromise the device a user has already authenticated with MFA.”

“You said there was a third way that he can get around MFA?” Dylan asked.

“That's right. He can exploit authorized MFA exceptions. Bob would identify an account operating without MFA requirements like a service account, and attack them directly. Or much more commonly, Bob could target legacy applications like POP or IMAP, which don't support MFA. You'd be shocked at how much info a cybercriminal can glean from reading your email.”

“What about stolen certs and session reuse?” Dylan asked.

“As a technique,” Agent Smecker began, “stolen certificates have been known for a while. But it's been talked about a lot lately because it was used in the SolarWinds breach. Basically, all an attacker needs to do is steal the private key to sign certificates. Another variation is the golden ticket attack, where the attacker uses a forged key that lets them control any resource in an Active Directory domain. It's like the golden ticket in Willy Wonka, except once you get in, there aren't any Oompa Loompas escorting you around; you can go wherever you want.”

“We'll work on this part when we get to the monitor and maintain step,” Aaron interrupted, “but this technique is a real challenge to detect since the requests look legitimate. But you were going to talk about session reuse as well?”

“This is like the MFA bypass scenario I talked about before. A cybercriminal will compromise a device with an existing authenticated session. Most MFA configurations have a default thirty-day period before they require the user to reauthenticate because they don't want to negatively impact user productivity. This gives the threat actor a window in which they can establish more permanent access into the network.”

“How often should users be required to reauthenticate?” Dylan asked.

“We don't have a lot of official data around this, but for higher-security areas some organizations require reauthentication every time a user logs in, which could be lots of times per day. Daily works for a lot of organizations because it's a more predictable user experience. But for consumers, it might be much less.”

“Oh, sorry, guys, I've got to run to our Identity Governance meeting,” Brent said.

“Perfect timing, actually,” Aaron said. “Dylan, you and Isabelle should tag along with Brent to get their input on some of the changes we're talking about. But the real goal will be to get their help in defining our Zero Trust identity policies.”

Brent was out of breath when they reached the conference room. The wall facing the hallway was all glass while the outer wall had windows facing the courtyard. The large conference table seated twelve people, but only a few seats had been taken. Brent said, “Tell them I'll be a second, I just need to grab something,” and disappeared down the hallway into a maze of cubicles.

Isabelle held the door for Dylan and he walked in. It was unusually hot in the room. Noor was talking quietly to Kofi at the other side of the room. Kim Self had just started the Zoom session and several people appeared on the large TV at the end of the table. She was fanning herself with a piece of paper. Instead of closing the door, Isabelle propped it open, then walked to the other side of the glass wall that ran along the hallway and propped the other door open.

A tall man that Brent hadn't seen before went over to a tall bladeless fan in the corner of the room and switched it on. He held his hand out to make sure air was moving, then put his face to the fan. “Please don't tell me someone hacked the air conditioning, too,” he said.

“Don't say that. The hackers might be listening,” Dylan joked, but stopped short when the man didn't smile. “I'm Dylan,” he said, extending his hand.

“Hi, Dylan. Olivia has told me a lot about you,” the man said, taking Dylan's hand firmly. “I'm Victor Vega. But please, everyone calls me Vic.”

“Oh, you know Olivia?” Dylan said, surprised.

“She's kinda my boss. I run our sales team,” Vic said.

Isabelle appeared beside Vic with a thin woman behind her. “Oh good, you've met Vic. Let me also introduce you to Mia; she's our head of human resources.”

“Mia Wallace. Nice to meet you, Dylan,” she said, shaking his hand. “I didn't realize that you'd be joining us today.”

Dylan was about to speak when Brent came in, carrying a large chocolate Bundt cake. There were several yelps of joy from around the room at seeing the cake. Dylan turned to Isabelle, confused at this new side of Brent. Isabelle shrugged.

“Brent's the man!” Vic said.

“I know, I know,” Brent said, turning to Dylan. “I promised I'd bake a cake when we finally finished our user access review workflow,” he said in explanation as Noor took the cake from him. “We'll be ready to start next week.”

“I really miss starting meetings out on a positive note,” Noor said as she cut a slice. “Sorry for the folks working remote today. We'll save a slice for you. For the folks who've not had the pleasure of meeting him yet, Dylan is here today to give us an update on Project Zero Trust.”

“Thank you, Dr. Patel,” Dylan said, regretting that he had just taken a bite of cake. It was delicious and he chewed for a few seconds before continuing. “We've started focusing on our highest-priority applications, and identity is one of the most important parts of any Zero Trust strategy. We're working with Isabelle to formally launch some identity-related projects, but we'll need this group's help in order to craft our policies.”

“The goal of this Identity Governance group,” Noor said, “has always been to secure our data while ensuring a seamless user experience and compliance. We know that having a team of IAM stakeholders is critical to the success of our identity program. We need to hear what's foremost on your minds.”

“What about reducing our costs?” Vic asked. “This Zero Trust project isn't cheap on top of what we're paying to clean up the hacks. I'm worried all these costs will impact our new product launch.”

“I'm less concerned about costs than I am about the damage to our brand,” April said. “If the new product launch is to be successful, we have to demonstrate that we've made real changes.”

“One big part of the identity project will be a role cleanup,” Brent answered. “We want to make sure that every user in our organization has a role assigned to them that's independent of their title. Those roles will have permission to access resources based on the job description. We know that in our early startup days, permissions were given to lots of people, and standardizing those permissions will help us automate the process of bringing new people on board.”

“That sounds like you'll need a lot of help from HR,” Mia said.

“We'll work with your business leads, Mia,” Brent said. “But the idea will be that we need to tie all accounts to an owner, manager, or sponsor of some kind. As we go through all of those accounts, we'll be looking for orphaned accounts or accounts where the password has expired, and we'll need someone to talk to before we remove them. But also, they need to know what specific permissions the account really needs. I can think of lots of cases where the person requesting an account asked for too many permissions out of fear or lack of knowledge. This should fix that.”

Kofi cleared his throat and waited for the room's attention. “The consultant's report indicated that the cybercriminal had been inside our network for months even though we had multifactor authentication in place. I found the passage stating that some systems allowed you to stay logged in indefinitely particularly concerning.”

“That was one of the policy items we wanted your help with. We need to make sure all applications are required to use MFA and make it a part of all applications by default before they're rolled out. But we also want to require users to reauthenticate daily, or even more frequently when doing a particularly important transaction, like authorizing a payment or deploying code into production, for example.”

“I actually really like that idea,” April said. “Sometimes when we have blackout windows that are set by the SEC, we need to make sure we don't accidentally disclose information for insider trading purposes. I'd love to have a reauthentication point before one of my team members can publish certain documents to the site. That wouldn't get in the way at all.”

“Brent made this?” Harmony asked as she took a bite of the Bundt cake. “OMG, this is good. Didn't see that coming.”

“Brent mentioned they were in the process of launching a user access review process next week,” Dylan said.

“That's perfect,” Aaron said. “And that actually brings us to the final step for the protect surface for identity: monitoring. User access reviews are a big part of that. Usually, users' access privileges are reviewed on a regular basis, like monthly or quarterly to make sure only the right people have continued access.”

“Brent said they'd start at quarterly and planned to increase the frequency as the identity team worked through issues,” Isabelle said, then continued eating her own slice of cake. “I can't believe how good this cake is. Would it be weird if I asked for the recipe?”

“Access reviews should also be triggered when any employee is promoted or transferred where access change occurs,” Aaron said. “Making your IAM program an integral part of all new application onboarding/major change discussions will also mean that all identity activity can be monitored in one central repository and correlated with other security events more easily.”

“Remind me again how monitoring is related to Zero Trust?” Brent asked, coming back into the room. “Isn't this something the Security Operations Center is supposed to do?”

“There are two main aspects of how your Zero Trust strategy plays out in practice,” Aaron explained. “First, it forces visibility into your environment and prevents bad things from happening. But we also don't trust that we got everything right the first time or that nothing changed without us knowing. So our Zero Trust methodology also needs to be able to detect when things go wrong. Obviously all identity components need to feed into your SIEM or UEBA tools. But we should also enable both basic and advanced auditing as well as monitoring for object and attribute changes in the directory.”

“Didn't we talk about UEBA the other day when you talked about the policy engine thing from the NIST standard?” Dylan asked.

“UEBA is really interesting,” Aaron said, “but what we really need when it comes to identity are integrations that share signals for identity. This is actually why the Identity Defined Security Alliance, or IDSA, has developed a framework to apply Zero Trust to each stage of the identity life cycle. The seven identity components are Identity, Device, Network, Compute, Application, Storage, and Data. The idea is that these seven components make up all of the different interactions a user could have in an environment, and each of these different areas should be able to send or receive signals to the policy engine. But these are the seven areas we'll need to ensure that we have visibility into to be able to successfully monitor and maintain the strategy as well.”

Aaron displayed the IDSA reference architecture document. “Sometimes you have a user passing through all these layers to get to the data. Other times, a process inside an application will use a service account through the network to access the data.”

“It seems like for every new protect surface from here on out, we'll want to build identity into the Zero Trust process so that we'll be looking at the complete end-to-end authentication process?” Dylan asked.

“Exactly,” Aaron said. “Ensure you're consuming all the elements of identity. You should be using identity in your firewall rules, at a minimum. But as you work with the Identity Governance group, you should also identify opportunities for reauthentication for each protect surface that will be frictionless to the end user.”

“There's another tweet from the hacker, Encore. It's like his name is designed to get more annoying the more he hacks you,” Harmony said as she scrolled through her messages.

“How do you know?” Brent asked.

“I started following him on Twitter,” Harmony said. “What?” she said at his surprised look. “Was I not supposed to?”

“I started following him too,” Rose said.

“That's fine, it's smart. I wish I had thought of it already,” Dylan admitted.

“Oh no,” Harmony sighed. “If you dig into the threads, he says one of the zero days would allow cybercriminals access to the camera to view inside people's homes.”

Key Takeaways

While your ERP system may be your crown, the jewels are the people connected with your organization. With identity there aren't people inside the network like in The Matrix. It's tempting to “trust” an identity, but with Zero Trust, the goal is to prevent and contain breaches by removing trust wherever possible. In practice, this can be done in a number of ways, but since identity is what enables your people to do their jobs or enables your customers to engage with you, it must be done in as seamless a manner as possible.

Identity requires a much more comprehensive understanding of how the business works than traditional technology services. Identity drives the business, offering not just authentication services to protect data but also helping the business connect with customers and provide more personalized services. Process always comes before technology. It's always more important to understand why a process needs to be in place before the technology is deployed for that task. The good news, however, is that most likely some of this work has already been done. Many organizations have done GDPR, HIPAA, or CCPA assessments, and these assessments can help jump-start the data flow mapping process that the Zero Trust methodology requires.

One of the most important criteria for a successful identity program is to have an Identity Governance group that meets regularly. This group should be made up of business owners and include representatives from HR, Legal, Risk, Privacy, and IT. This group should define owners of identity and ensure that the identity program objectives are aligned to business priorities.

The cornerstone of any cloud security strategy is identity. While we will focus on cloud in a later chapter, your legacy on-premises technology environment has relied for years on firewalls or other controls at Internet egress points. Those controls are no longer effective when it comes to the cloud. Many workers are now able to work remotely, so it's more important than ever to eliminate the “chewy centers” of our legacy networks that John Kindervag described in his original paper where he proposed a Zero Trust approach to security.

Getting identity right in cloud environments is critical for both service delivery and protecting the data that runs the business. In the cloud, identity provides the foundation of the majority of your security assurances.

As Agent Smecker illustrates in the story, getting identity right also means being able to provide answers after something bad happens. The Identity Defined Security Alliance (IDSA) has a framework of the seven components of a digital system that consume identity. How each of these elements interacts with identity in your environment determines the identity-defined security approaches that you can use to construct your Zero Trust strategy. The seven IDSA components are:

• Identity
• Device
• Network
• Compute
• Application
• Storage
• Data

For all protect surfaces, the complete end-to-end authentication process for how identity is consumed should be detailed in the data flow mapping stage of the Zero Trust methodology. The goal will be twofold: First, you should ensure that you're consuming all the elements of identity and leveraging them when creating Zero Trust policies in each protect surface; second, for each flow, and with the help of the business owner of that identity, you should identify opportunities for reauthentication that will be frictionless to the end user.