Dylan knocked on the slightly open door to Donna's office. “Is this still a good time to talk?” he asked. Donna was wearing a large pair of noise-canceling headphones and typing on a large manual calculator that printed numbers on a receipt as she typed. Dylan took two steps in and waved to get her attention.

“Dylan? Hello,” Donna said, peering over papers arranged neatly into stacks that reminded Dylan of a 3D rendering of a map of downtown. She took off the headphones and said, “Perfect timing, I was just finishing up. Please have a seat.” A small circular table near the entrance was covered with stacks of binders. The topmost binder read “2021 Audit Report.”

“How is Project Zero Trust going?” she asked.

“It's been a couple weeks, but we're starting to make progress. But the consultant kicked me out and said I needed to go figure out how the business makes money. Isabelle suggested I should start with you,” Dylan said as he sat down in the chair next to the circular table.

“That's quite the consultant you've got there. What do you want to know?” Donna asked.

“I know we have pretty good margins on each TreadMarch. Then there are the work-appropriate workout clothes. The monthly subscription is another big part of that. Zero Trust needs to be able to protect and enable the business at the same time,” Dylan explained.

“What about that hacker?” Donna asked as she walked around the desk to sit in the chair next to Dylan.

“Unfortunately, the data he released was real. Thankfully, it was just a bunch of old telemetry from the treadmills that was being stored in the cloud, so there wasn't any personal information in it. I think it underscores how important the work we're doing is right now,” Dylan said as he opened his notebook to an empty page and wrote the date at the top.

“What questions did you have, then?” Donna asked.

“What are your biggest priorities right now as CFO?” Dylan asked.

“There are several key areas that we'll be focusing on this year. We need to ensure that we have the financial data to enable our leadership to make the best strategic decisions,” Donna explained. “The pandemic has massively increased our profitability as people aren't going to gyms, but we don't expect that to last forever. At the same time, we're preparing for our new product launch, which we expect to take the company in a whole new direction. To be able to navigate that, we've got to have the right insights to be able to respond to our existing consumers and new consumers so that we're investing in the right areas at the right time.”

“I think it's really cool that you're making data-driven decisions,” Dylan said. “Do you have enough support to be able to make the insights you need?”

“Oh, numbers always have a story to tell. You just have to listen to them. I guess you're looking into the Ides?” Donna asked.

“The Ides?” Dylan asked.

“Oh, you hadn't heard it called that yet?” Donna said apologetically. “It's what most people call our ERP system. It's lovingly referred as the Ides of March. That's when Julius Caesar was killed, but there was this witch who told Caesar to beware the Ides of March. So. Beware.”

“Have there been issues with the Ides?” Dylan asked.

“Nothing specific. It's just incredibly complicated, and I don't think anyone knows how it works. They did a lot with security a few years ago for credit cards. Now our stores use end-to-end encryption, which means that the credit card number is encrypted at the card reader itself and isn't unencrypted until it reaches the payment processor. This has greatly reduced our costs when it comes to credit card compliance because of how much simpler our controls are. That's an example of Zero Trust, right? Not trusting the devices or the network reduced our costs. I just signed our latest PCI compliance report, if you want to see that. I'm sure I can find it here somewhere.” She stood up and began looking through the different stacks of binders on the table. Seconds later a binder labeled PCI assessment results was in Dylan's hands.

“I'll check that out,” Dylan said, putting the binder into his backpack. “I was actually hoping this would just be the start of a conversation. I've always thought that finance was just another part of the security team. You help create the budgets, but you also prevent fraud. We need your expertise in helping make sure a breach never happens to us again. What are the biggest concerns you have right now?”

“What about how money leaves the organization?” Donna said. “Isn't that how all those business email compromise things happen?”

“Exactly. Let's say I've got a new vendor, like this consultant. How would you find out about it to know who to pay and how much?” Dylan asked.

“That's easy. One of my team would enter the vendor into Ides. Then we'd attach an invoice and cut a check.”

“Who has access to create a new vendor or to write a check?”

“Everyone on my team,” she said, but then hesitated. “I don't know if anyone outside my team has access. I used to get reports on this at my last job. Is that something we can set up?”

“You bet. What about reports of all new vendors that get created? Or all invoices?”

“That would be amazing,” Donna said. “I thought we'd need to buy some new software to be able to do that. I've always wished we could have multiple approvals for invoices. Is that something we can do as well?”

“We definitely need to do that! I always like to think about processes before technology,” Dylan said. “We're always focused on getting shiny new technology to solve our problems. But the biggest frustration from people is always that they need to do something to get their job done and the technology makes it harder.”

“Process before technology. Can I steal that?” Donna asked.

“Of course,” Dylan laughed.

“It's funny. I think we're both doing the same thing,” Donna observed. “I need Ides to understand how the business operates in real time to protect the business from going the wrong direction, and you need to understand how the business operates in order to protect Ides. There's a nice symmetry there, don't you think?”

Dylan walked into the MarchFit lobby buzzing. He noticed MarchFit's slogan engraved into the wall above the entrance to the building: “Every Step Matters.” As he walked up the stairs to the conference room, Dylan thought about all the steps he had taken on his treadmill at home. He thought about all the outdoor walks he had taken while on conference calls over the last two years. It didn't feel like a particular step made much difference at the time. But each step made the one after that possible.

He paused outside the door to the conference room. Aaron was at the video wall explaining something, but Dylan couldn't hear what it was. He watched as the team interacted, each feeding off the energy of the person before them.

Harmony was standing, gesturing animatedly toward Aaron. Dylan pulled the door open slightly so he could hear them speak. “I keep hearing security experts talk about how we should just be doing the basics, but they never really say what the basics are beyond patching and MFA. Isn't that what we're doing with Zero Trust?” she asked. Dylan smiled seeing the team really get engaged.

“Part of the problem with just saying to follow best practices is that everyone's environment is so different,” Aaron explained. “It's great to follow best practices, but there are actually a lot of different ways that you can accomplish implementing them—and how you implement them and what you implement them on takes a lot of specific knowledge about the environment. As a strategy, Zero Trust helps focus your efforts toward the most effective ways of securing your organization. This is why mapping the transaction flows is one of the first things that you need to do.”

“We're ready to start the first major protect surface,” Aaron said as Dylan walked in. “Your business continuity plan has several high-priority applications that you need to secure, but I think we're ready to start work on our ERP system. We've focused primarily on network-based controls in the applications we've looked at before, but to implement Zero Trust in the ERP, we'll need to dive a little deeper into the application.”

“We call it Ides,” Dylan said. Brent and Nigel both smirked at this.

“It sounds like you're ready to beware of the Ides of March?” Aaron said. “I take it your conversations with your stakeholders are going well, then. Did you learn anything about the ERP system?”

“It seems like there are a lot more ways that we can lose money than we can make it,” Dylan said, defeated.

“Dylan, you're not just learning the business outcomes,” Aaron encouraged. “You're creating the relationships and trust that you'll need to help sustain the changes that we're making. We need to align security with the business, and you can't do that tucked away in a conference room or a data center. The people in the business are the business, and you have to align with them.”

“That helps, but the ERP system is huge and incredibly complex,” Dylan said. “But we'll give it a try.”

“No!” Aaron said. “Try not. Do. Or do not. There is no try.” The table erupted with howls of laughter at this. “Sorry, I've always wanted to say that,” Aaron responded between laughs.

“Where should we begin?” Rose asked.

“I'm glad you asked, Rose.” Aaron was serious again. “I apologize for not telling you this sooner, but when we began, I asked for a security consultant to come in and perform an assessment. And she's ready to give us her report.” With a few clicks, a Zoom window appeared on the video wall and a woman appeared on the screen. “This is Peng. We've worked together on several projects and she's an ERP security specialist. What have you found, Peng?”

“Let's start with the good news.” Peng shared her screen showing the text of the report. “We saw that there were a number of good security practices already in place with your ERP system. One of the first things we look at is the default usernames for the application itself. Those had been changed. It looks like many of those defaults had been changed to be references to Julius Caesar.”

“That makes sense.” Harmony chuckled.

“Also, the ERP system has been configured to encrypt all traffic by default, including the backend connections to the database. And the databases themselves are encrypted as well so that even if the servers running the database are compromised, an attacker wouldn't be able to get access to the data. Although database encryption isn't required, there are state privacy statutes that indicate if the data is encrypted and you experience a compromise, you don't have to do a breach notification.”

“This is going to be easier than I thought,” Brent said.

“Unfortunately,” Peng interrupted, “that's all the good news.”

Nigel crumpled up a piece of paper and threw it at Brent. “Stop jinxing us, mate!”

“The bad news,” Peng began, “is that the ERP system itself hasn't been patched in about five years. This means it doesn't have the latest software updates, new security features, et cetera.”

“That makes sense,” Rose said. “The company was started about five years ago.”

“So it's never actually been patched since we started?” Dylan asked.

“This is actually a very common scenario,” Peng said. “Usually it happens for a number of reasons. Maybe the team is understaffed and has to prioritize meeting project deadlines. It could be because the ERP team doesn't have the organizational support to accommodate any downtime. You're actually in better shape than most other ERP implementations, which haven't been patched in ten years.”

“That doesn't make me feel any better,” Dylan said.

“Let's keep going. Peng, can you tell us about how the transactions flow through the ERP system?” Aaron asked.

“Sure. Let me start with the 10,000-foot overview. ERP systems don't come out of the box ready to support your business. There are a lot of different modules you can choose from. And most businesses customize all these different parts of the application to suit their business with specialized developers. Developers work on their code in a development environment, which is usually an exact copy of the main production system so that they can make sure their code works. Then the code is migrated to a test environment, and if it works there after some review, it is then migrated into production. From a process perspective, MarchFit does have the appropriate separation of duties so that developers can't migrate code into production by themselves; they have to rely on others to do this work for them.”

“That's good. What issues did you find?” Aaron asked.

“One challenge we noted is that MarchFit uses real data in dev and test. So the developers have access to real personal data. There are tools available to mask that data or to use dummy data instead. We highly recommend this.”

“Is that it?” Brent asked. “That seems pretty minor.”

“Have you ever seen Superman III?” Peng asked, not waiting for an answer. “Your ERP system uses a specialized code language that isn't supported by most commercial code scanning tools. This means that even though you have good separation-of-duties processes, and even if you're running vulnerability scans, you wouldn't be able to detect Richard Pryor injecting code that steals pennies from every transaction, for example.”

“Is Richard Pryor one of our developers?” Harmony whispered to Rose. Rose shook her head silently.

“Even though you removed the default naming conventions, there were a large number of people with superuser status on the ERP system itself, which is a concern. And when we looked further into the code, there were hard-coded passwords inside the code. We also saw that a former developer had created a finance report in production that was still being sent to his Gmail address. Although there is extensive user acceptance testing during deployments, this is all being done in the code without oversight. So, in short, the internals of an ERP system are usually a blind spot for security teams.”

“We also know that although MarchFit has a vulnerability management program and does regular scans, they don't scan inside the ERP system,” Aaron explained.

“Oh, Richard Pryor was a comedian!” Harmony exclaimed, looking up from her computer. She looked up and realized she had said it out loud. “Sorry!”

“Oh no, he's great,” Peng said. “You should definitely check him out.”

“So what kinds of things could go wrong with these issues?” Dylan asked.

“From a vulnerability perspective, we should be concerned that a disgruntled developer with superuser access could create a fake company, then create a fake invoice, and have payments sent directly to that account. Or a malicious actor could inject a bit of code to ship new treadmills to random addresses all over the world instead of where they're supposed to go.

“A hacker could really do all that?” Rose asked.

“I've detailed the transaction flows in my report,” Peng said. “For each transaction, we walk through both the business use cases, but we also walk through how each transaction could be used against the business. We call that a ‘misuse case.’ We've provided a prioritized list of each of the misuse cases, but the ones we've already gone through are the major ones that there weren't any compensating controls to prevent or even detect.”

“Thank you, Peng. Very helpful,” Aaron said. “She's already sent us a copy of her report, which details all of the transaction flows for the second step in the Zero Trust methodology. As we move on to the third step, architecting the Zero Trust environment, we'll be doing something a little different.”

“That's sounds scary, considering this is such an important system,” Dylan said.

“Most of the time, we don't need new tools to implement Zero Trust for a particular protect surface,” Aaron said. “Zero Trust isn't any one tool. But in this case, we are missing a key tool in our toolkit. Imagine a general commanding an army. They'd have soldiers, artillery, radios, and maybe even tanks. They could develop a strategy with the tools they had at hand. But imagine that general didn't have any fighter jets. That would be a pretty big gap in their capabilities that would be difficult to overcome no matter how good their strategy was.”

“So we need a new tool?” Isabelle asked.

“In this case, yes,” Aaron answered. “There is a specialized tool I had in mind to help address the gaps around the ERP system, Ides. Here are the gaps that Peng identified in her report.” With a flourish, Aaron waved his hand and displayed the report on the wall monitor and the following bullets appeared:

• Specialized programming languages are not supported by most security code review tools.
• ERP change control is often a manual process and isn't built into the ERP system itself.
• Traditional vulnerability management tools don't scan applications or code updates.
• Compliance-management mechanisms, like enforcing password standards, configurations, or access to sensitive data, aren't native to ERP systems.
• Application logs are not digestible by most security logging systems (SIEM), meaning Security Operations Center teams monitoring the environment are missing critical data.

“ERP systems are incredibly complex,” Aaron explained. “Normally you would do an RFP for a new service like this, but 85 percent of the Fortune 500 all use the same ERP system, and there is already a commercial solution out there that specifically addresses these challenges. But this won't be the case for most of our more complex protect surfaces. Isabelle, can you spin up a new project, please?” “Of course,” Isabelle said. “I'll pull in the ERP team and work with Purchasing.”

“We'll also need to make some process changes,” Aaron continued. “Dylan, I want you to work with your new friend on the finance team to negotiate a weekly maintenance window where the ERP team can begin applying patches.”

“I'll talk to Donna,” Dylan said.

“I'm wondering why we didn't start with identity as our primary protect surface?” Brent asked. “There is clearly a lot of work that needs to be done with Ides, but even after we do all that work, a compromised account could still cause a lot of problems, right?”

“I agree that identity is a critical service. In fact, it will be the next protect surface we address,” Aaron answered. “But we started with the Ides as the first of the primary protect surfaces for one main reason. And it's the first of the Zero Trust design principles. By starting with Ides, we're focusing on the business. We're forcing ourselves to understand how the business makes money.”

“I guess that makes sense,” Brent conceded.

“But there's another reason I wanted to hold off on identity,” Aaron said. “We're thinking of all the specific misuse cases around the ERP system. And that brings us to the next step in the Zero Trust methodology: creating policies. We need to begin building policies based on identities. So in a way, we're practicing identity now so it will be that much easier later on.”

“We got MFA set up for Ides last year,” Brent offered.

“What about continuous reauthentication?” asked Rose.

“Uh-oh,” Aaron exclaimed. “Somebody has been reading the NIST standards.”

“What's wrong with that?” Rose asked. The others all looked up at Aaron.

“It's not bad or anything,” Aaron laughed. “They did a good job capturing a good conceptual framework for the architectural concepts we use in Zero Trust.”

“But?” Dylan asked.

“But,” Aaron said, “NIST 800-207 is focused on architecture, which is important. But there's not much guidance for what to do or where to start if you're going to do the work of maturing your information security program to embrace the strategy of Zero Trust. That's what the four design principles and the five design methodology steps give you. The design principles and methodology were developed by John Kindervag over a decade of actually doing the work of implementing successful Zero Trust projects at hundreds of companies.”

“That makes sense,” Dylan said.

“Sorry, dumb question, but what's a NIST?” Isabelle asked.

“It’s the National Institute of Standards and Technology,” Rose explained. “It's a government group that comes up with standards for almost every industry. They have a lot of standards around IT and security.”

“The reason that I get frustrated with the NIST Zero Trust architecture,” Aaron explained, “is that there's nothing in it about aligning with the business. Remember, Zero Trust is the strategy for preventing a security breach at your unique organization, and there are lots of ways to accomplish that. The NIST Zero Trust Architecture lists several ways to accomplish Zero Trust, but you could use any or all of those approaches in any organization. Many of the recommendations, if actually implemented, would make it harder for employees to do their work or for consumers to use your products with what is commercially available on the market. But as we start to define our Zero Trust policies for Ides, you should understand the NIST 800-207 Zero Trust Basic Tenets.” Aaron waved his hand and displayed the tenets on the video wall:

• All data sources and computing services are considered resources.
• All communication is secured regardless of network location.
• Access to individual enterprise resources is granted on a per-session basis.
• Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes.
• The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
• All resource authentication and authorization is dynamic and strictly enforced before access is allowed.
• The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications, and uses it to improve its security posture.

“Each of these tenets applies to identity and access management, or IAM,” Aaron explained. “How employee logging in will need to be vetted. Again, this applies to employee IAM but not consumer IAM.”

“Isn't there something called UEBA that the security guys have been talking about for a while? Is that what this is?” Dylan asked. To Isabelle he explained, “That stands for user and entity behavior analytics.”

“In a way, you're right, Dylan,” Aaron answered. “Many of the Zero Trust frameworks, from Gartner to Google, have come up with this idea of a policy engine. The idea is that you should be able to take the kinds of things that UEBA was supposed to give you, but instead of just reporting them to your security team, you'd be able to automatically act on that data inside your ERP system. Or any other protect surface, for that matter. In practice that's pretty hard to do. There are some companies out there building policy engines, but they don't work with every bit of software out there. At this point, we're going to do what we can inside the ERP system. But we'll be able to do more once we get to our endpoints. Remember, we're starting from the inside and working our way out to the edge.”

“I've heard some people talk about assumption of breach when it comes to Zero Trust,” Rose said. “But we haven't talked about that yet.”

“There are some implicit assumptions that NIST creators want you to make when thinking about Zero Trust,” Aaron said as he waved his hand and displayed the NIST Zero Trust view of the network:

• The entire enterprise private network is not considered an implicit trust zone.
• Devices on the network may not be owned or configurable by the enterprise.
• No resource is inherently trusted.
• Not all enterprise resources are on enterprise-owned infrastructure.
• Remote enterprise subjects and assets cannot fully trust their local network connection.
• Assets and workflows moving between enterprise and nonenterprise infrastructure should have a consistent security policy and posture.

“These are all very specific reminders that when it comes to computers or networks, you should have Zero Trusts to give. Some definitions of Zero Trust also include the idea that you should always assume that you've been breached and apply as many trusts as you would give in that situation, which is also zero. Your tech stack is always going to be evolving, so your security strategy should plan for an evolution over time of your technology and provide the equivalent level of security, regardless of whether it's on premises or in the cloud, whether it's a containerized app or a hardware appliance.”

“Somebody has Zero Trust issues,” Harmony joked.

“We all know by now that the final step in the Zero Trust methodology is to monitor and maintain,” Aaron began. “But as we've seen with all the other parts of the ERP system, they don't work with our existing controls, and this is just as true with the ERP. Application logging isn't being sent to our centralized logging system.” To Isabelle he explained, “We call that a security information and event management system, or SIEM.” She nodded her thanks and he continued, “And because these alerts aren't going to the SIEM, the Security Operations Center or SOC would never get an alert that something has gone wrong. We'd be relying on the finance department to find suspicious payments or for customers to start complaining that their treadmills hadn't arrived.”

“Why wouldn't the SIEM be able to receive the ERP logs?” Dylan asked.

“It wouldn't matter, because even if those logs were being sent to the SIEM, they wouldn't be able to read those logs. Most commercial SIEMs like the one we use can't understand logs from an ERP system. It would be a huge undertaking to get these into your SIEM, and when the next change happened, you'd need to start this all over again.”

“So it sounds like we need yet another tool to be able to monitor all of that activity in a central place?” Isabelle asked.

“Actually, the one I had in mind bundles many of the controls that we've been talking about into a single system. And from that system you can send alerts to your SIEM so that your SOC can respond to threats in real time, as well as monitor for suspicious activity as changes are made.”

Dylan looked down at his phone, which was vibrating on the table. He picked it up and unlocked it. “I just got a text from Noor,” he said. “The hacker is claiming that he's stolen all of our user credentials and is offering them for sale on the dark web. Here's the tweet.” Dylan sent the image to the video wall.

“That's all our customers,” Rose said.

“Noor says the security consultant is reviewing. They're checking the dump to see if it actually contains real data or if it's bogus,” Dylan said.

Key Takeaways

This chapter focused on what many organizations consider their crown jewels: their ERP and CRM systems. Some organizations use a single software provider for both of these, whereas others have the two functions separate. The unique challenges around ERP systems require highly specialized knowledge, and many smaller organizations may choose to bring in specialists to help understand the often complex environments that ERP systems can create.

According to some reports, up to 85 percent of the Fortune 500 use the popular ERP system SAP to enable their businesses to have the insights they need. And although SAP and other ERP systems can be secure, they are not necessarily secure by default. There are a number of unique challenges that these systems can create:

• Specialized programming languages are not supported by most security code review tools.
• ERP change control is often a manual process and isn't built into the ERP system itself.
• Traditional vulnerability management tools don't scan applications or code updates.
• Compliance management mechanisms, like enforcing password standards, configurations, or access to sensitive data, aren't native to ERP systems.
• Application logs are not digestible by most security logging systems (SIEM), meaning Security Operations Center teams monitoring the environment are missing critical data.

In the ERP system, it's also very important to understand how users are assigned permissions to interact with applications. The next chapter will focus on identity and Zero Trust, so it is also important to understand how some Zero Trust frameworks have integrated these two important concepts.

There have been a lot of attempts at creating a Zero Trust framework. Gartner, Forrester, and even Google have put their own spin on Zero Trust. But the NIST Zero Trust Architecture is the one that you're most likely to see in practice. In the future, vendor contracts may require companies to certify that they are NIST 800-207 compliant, so viewing your Zero Trust implementation from a NIST perspective is an important guide for measuring success.

There are many definitions of Zero Trust. NIST defines it as follows (https://doi.org/10.6028/NIST.SP.800-207):

Zero Trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero Trust Architecture (ZTA) is an enterprise's cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a Zero Trust Enterprise (ZTE) is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan.

This definition can be rewritten as the following equation:

This definition was intended to add identity services (ZTA) to a network-centric view of Zero Trust. And the definition concludes that the only way to have a truly Zero Trust Enterprise (ZTE) is to have both identity as well as network controls. Because identity is so important to Zero Trust, we will discuss it in more depth in the next chapter. However, this book flows from John Kindervag's original design methodology, which flows from protect surfaces.

There are seven basic tenets of Zero Trust according to NIST 800-207:

• All data sources and computing services are considered resources.
• All communication is secured regardless of network location.
• Access to individual enterprise resources is granted on a per-session basis.
• Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes.
• The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
• All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
• The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture.

There are also six challenges from a network perspective that the NIST Zero Trust Architecture document specifically addresses, and that every Zero Trust project will need to address:

• The entire enterprise private network is not considered an implicit trust zone.
• Devices on the network may not be owned or configurable by the enterprise.
• No resource is inherently trusted.
• Not all enterprise resources are on enterprise-owned infrastructure.
• Remote enterprise subjects and assets cannot fully trust their local network connection.
• Assets and workflows moving between enterprise and nonenterprise infrastructure should have a consistent security policy and posture.