Project Zero Trust

Because of the “trust” model, traffic—by default—can flow from a higher “trust” level (inside) to a lower “trust” level (outside of a DMZ) without a specific rule. This is very dangerous. Once an attacker gets purchase inside your network, no policy stops them from setting up a command and control channel or from exfiltrating data. This is a significant flaw in the technology, but, sadly, everyone seemed to be okay with it. When I would put in outbound rules, both clients and co-workers would get upset. “That’s not the way it’s supposed to be done!” I left many client sites dejected because it was self-evident to me that bad things were in store for the client.

Ref. 6F88-A

So I learned to hate trust. Not trust between people, but “trust” in the digital realm. So I started studying the concept of trust, thinking about it, and asking questions like “why is ‘trust’ in digital systems?” It became clear that this “trust model” was broken and was the proximate cause of numerous data breaches.

Ref. C245-B

I discovered that there are other problems linked to the “trust model.” The first is the anthropomorphization of technology. To make complex digital systems more understandable, we’ve tried to humanize them through our language. For example, we say things like “George is on the network.” Now I’m pretty sure that my friend George has never been on a network in his entire life. He has never been shrunken down into a subatomic particle and sent down a wire to some destination like an email server or the public Internet. This rarely ever happens in movies: in Lawnmower Man or Tron, but even in The Matrix, they have to plug in. But how do I tell this story?

Ref. C54B-C

The first big thought I investigated was that injecting “trust” into digital systems was a stupid idea. I was now free to explore that contentious statement. There was no vendor or co-worker to put the kibosh on thinking. Freedom—that was the great gift that Forrester gave me.

Ref. 8B5A-D

The penultimate moment came in 2021, when President Joe Biden issued his executive order on improving cybersecurity in the federal government, which mandates that all federal agencies move toward adopting a Zero Trust architecture. If you had told me a decade ago that this would happen, I would’ve told you to get back in your DeLorean and accelerate it up to 88 mph because that would never happen. But it did, and it’s changed everything. Primarily it has inverted the incentive structure. It used to be that only the radicals inside an organization were Zero Trust advocates. Now, it’s okay to adopt Zero Trust because of President Biden. He moved the needle.

Ref. C04D-E

The most effective means we have available to protect ourselves when it comes to cybersecurity is prevention. And the most effective strategy for prevention is Zero Trust. To be successful at any endeavor, you need a strategy. Many organizations struggle with success when it comes to cybersecurity—not because they are doing nothing but because they don’t have a consistent strategy for protecting their data. Zero Trust is a strategy for protecting your organization’s most important assets. This strategy focuses on preventing breaches by eliminating one of your biggest blind spots when it comes to computers and computer networks—trust.

Ref. 49ED-F

Zero Trust is the bridge between the unique goals of your business and the specific tactics needed to secure the business. A 2020 report by Okta indicates that 60 percent of organizations in North America are currently working on Zero Trust projects, and President Biden has issued an executive order to federal agencies to implement Zero Trust in government.

Ref. A485-G

Readers will learn: John Kindervag’s five-step methodology for implementing Zero Trust The four Zero Trust design principles How to limit the blast radius of a breach How to align security with the business Common myths and pitfalls when implementing Zero Trust Implementing Zero Trust in cloud environments

Ref. 1DF5-H

“Ma’am,” one of the suits next to Noor spoke up. Unlike Noor, his suit was wrinkled and didn’t seem to fit quite right. “We see this issue come up frequently. There are scam ransomware actors out there. We can tell when this is the case, because they’ll use the same bitcoin wallet for all their victims. In those cases, you’ll see lots of transactions where their victims tried to pay up.”

Ref. 3F34-I

“It’s an accounting issue,” Peter explained. “The cybercriminal needs to know which victims have paid and which haven’t. The only way to do that is to have a different bitcoin wallet for each victim. Seeing that the bitcoin wallet is empty means this cybercriminal is serious.”

Ref. 9A2B-J

Isabelle leaned over to Dylan and asked, “What’s an EDR tool?” “It’s like antivirus software on steroids,” Dylan whispered. “It stands for endpoint detection and response. Old antivirus programs would use a kind of fingerprint to find malware, but the bad guys figured this out and would use different fingerprints. EDR works like facial recognition, so it doesn’t matter if you grow a beard or put on glasses. It can also take action to kick the bad guys out.” Isabelle nodded thoughtfully as the conversation

Ref. 43FA-K

Officer. “It will hurt the same whether it’s a day or a week. We can handle it for now, but we need to start thinking about the long term. Customer melt is a concern. But frankly the bigger concern will be the recovery costs, which are still unknown.”

Ref. 1C69-L

“I don’t really know enough about all our technology to answer …” Dylan responded, but was interrupted. “This isn’t a technical question. This is a philosophical question. Do you believe that prevention is possible?” The man had tented his fingers waiting for Dylan to respond. “I suppose,” Dylan began, “that we have to believe prevention is possible.” The man waited several seconds for Dylan to continue, then asked, “Why do you have to believe that prevention is possible, Mr. Thomas?” “Don’t you have to believe that success is possible in order to have success? If we didn’t believe we could prevent cybercriminals from breaking in, we’d unconsciously make it happen. Also, I’d be crazy for making this my career and not believe I could make a difference.” “Next question. What’s the purpose of cybersecurity?” the man asked, folding his arms. Dylan considered. “Security is only here to enable the business to keep running smoothly.” The man nodded wisely at this and was silent for a long time. “Was there another question?” Dylan asked, turning to Noor and Olivia.

Ref. ABAD-M

“Dylan,” Olivia answered, “you’re definitely not being fired. A few hours ago, I asked Dr. Patel here what the most cutting-edge security program was in the world. And Dr. Patel, you said?” “Zero Trust,” Noor answered. “Do you know what Zero Trust is, Dylan?” Olivia asked.

Ref. 55A0-N

burst into laughter. Noor finally relaxed in her seat. “No. I was convinced because it’s actually a strategy for security. This is the issue that Noor and I have been debating. With any other goal or objective in our business, we’ve got a strategy for achieving it. Our goal in security is to prevent bad things from happening. I know we can go buy tools or implement more tech to add to security, but how do we know we’re on the right track? In every other area of the business we have a strategy, and Zero Trust is going to be our security strategy moving forward.”

Ref. C033-O

“You’ve heard that an ounce of prevention is worth a pound of cure?” Olivia asked Dylan. He nodded. “That’s what I expect of Zero Trust. That’s why Aaron asked you about whether you believe in prevention. We believe that prevention is the most efficient way of stopping breaches, and Zero Trust is the best strategy for implementing prevention in technology.”

Ref. 5976-P

Trust is a vulnerability. Zero Trust is a cybersecurity strategy that says that the fundamental problem we have is a broken trust model where the untrusted side of the network is the evil Internet and the trusted side is the stuff we control. Therefore, organizations don’t do any real security on the trusted side. However, almost all data breaches and negative cybersecurity events are an exploitation of that broken trust model. Zero Trust is about getting rid of trust when it comes to technology. How much trust should you have in a digital system? The answer is zero. Hence, Zero Trust.

Ref. F8CF-Q

The primary goal of Zero Trust is to prevent breaches. Prevention is possible. In fact, it’s more cost effective from a business perspective to prevent a breach than it is to attempt to recover from a breach, pay a ransom, and deal with the costs of downtime or lost customers.

Ref. FA70-R

Zero Trust is more than just a marketing buzzword. Zero Trust isn’t any one specific tool that you can buy, because you can use many different tools to achieve the same objectives. Zero Trust isn’t a reference architecture, because each implementation of Zero Trust will be completely customized.

Ref. 5AE4-S

Aaron paused and took a deep breath. “Let’s back up a bit, and start with what a strategy is. A strategy is like a plan on how to achieve a specific goal, right? So at the end, you’ll know when you’ve reached your goal. Now, here’s my question: How do you know when you’ve successfully achieved your goals with defense in depth?” “Wouldn’t you know when the number of successful attacks starts to go down?” Dylan answered. “You don’t control the number of attacks the bad guys send against you, and you may not always know whether they’ve been successful or not. How many layers do you need to keep the bad guys out? Eight? Ten? Twenty? This is why embracing defense in depth as your strategy really turns out to look a lot more like ‘expense in depth.’ There’s no measure for success. And you’re spending money you don’t have on things you don’t need to protect.”

Ref. D1AA-T

“What about our attack surface?” Dylan asked. “I’ve heard security people at conferences talking about shrinking the attack surface. Shouldn’t we be doing that, too?” Aaron laughed. “The whole world is your attack surface! Any person or device anywhere on the planet could unwittingly be used to attack you. Instead, with Zero Trust, we focus only on the things that we can control. This is why we shrink it down to something very small and easily known, like the ‘protect surface.’”

Ref. E0F8-U

“Harmony, lots of organizations use consultants or industry analysts to decide which are the best products to buy. This isn’t a strategy, either. Having the best products doesn’t stop organizations from getting breached. What really matters is making all those separate elements work together in one integrated system that is custom tailored to fit your unique business.”

Ref. DC80-V

“There are only nine things you need to know to do Zero Trust. Nine things. That’s all. Anybody can remember nine things, I hope. Right?” Aaron pulled up a slide, displaying it next to the picture of the MarchFit network infrastructure: Focus on business outcomes. Design from the inside out. Determine who/what needs access. Inspect and log all traffic. “There are four design principles and five steps to applying it. But the first of all the design principles is to focus on the business outcomes. If you don’t know why you’re doing something, you can’t protect it. So how do you guys make money?”

Ref. 0AE7-W

“Just looking at the picture, you can tell that this network was designed from the outside in.” Aaron pointed at the network diagram. “The detail in the picture focuses on the endpoints at the edge and then goes inward. That’s why it fails, because we don’t know what we’re protecting.”

Ref. 867F-X

“This is why the third step we have is least privilege control access on a need-to-know basis,” Aaron added. “Ask the question, does so-and-so need to have access to that data to get their job done? That’s how I tell them. Don’t use the words ‘least privilege.’ Say, ‘Aaron, do you need that access to that data to do your job?’ I’ll bet most times the answer is no. We give too much access to too many people for no reason.”

Ref. E3DB-Y

Aaron nodded. “Then the fourth step is, inspect and log all that traffic, because in cases where we’ve seen there were rogue insiders or compromised accounts, no one looked at their packets post-authentication. We have this movement that Zero Trust equals identity and it doesn’t. We’re going to say that in the end, it consumes identity. You need to look at the packets post-authentication and see what they’re doing. Is there attack traffic in there? Are they downloading thousands of documents? Are there hundreds of SSH connections outside the company? To even have a chance at detecting those anomalies, you need to have the data in the form of network or server logs.”

Ref. 839D-Z

“The only way to eat an elephant is one bite at a time. Everybody thinks, ‘Oh, how are we ever going to implement Zero Trust?’ Our environment is big so we break it down into little sections. You take a big problem, and you break it down into really small problems, and that’s how you solve it. You can’t do everything at once. That’s why the first step in Zero Trust is to find the protect surfaces. You already know what these are. You’ve got your Business Continuity Plans and your Business Impact Assessments that tell you what the most important applications are in your environment.”

Ref. 6A25-A

“This is one of the most common issues with implementing software with a Zero Trust approach,” Aaron explained. “You only want to open the ports and the addresses needed and nothing else. I’ve seen documentation that tells you not to run a firewall at all. Some software guides don’t tell you all the ports you’ll need to open up, or sometimes they will tell you the wrong port numbers. Sometimes they don’t document all the dependencies needed to harden a server, or they call on a library that we didn’t know we needed as a prerequisite. You just need to keep in mind that all we’re trying to do is create a micro-perimeter around a protect surface. You don’t have to lock down everything inside the protect surface, because you’re containing the blast radius to that protect surface.”

Ref. 9506-B

“Does anyone notice what’s wrong with this picture?” Aaron asked. “The list of ports doesn’t match up,” Rose said. “The firewall policy allows a bunch of different ports to be open that aren’t running on the server itself.” “This is more common than you think,” Aaron observed. “Often servers will be decommissioned and new ones built with the same IP address. But no one tells the firewall admin, which it looks like may have been the case here. Dylan, take a note to review your server workflow process to look at decommissioning

Ref. DAC3-C

“Good catch, Harmony. This is one of the most common issues with how admins have configured firewalls for a long time. The idea was called a ‘trust model,’ and the way we trained firewall admins for years was that a server with high trust could always talk down to lower levels of trust with no restrictions. But, as we saw in the SolarWinds case and in all malware cases that have command and control, if you don’t have a rule that specifies that this resource can only talk to these certain things, then it can—and will—talk to anything on the Internet. There is never a time that any resource on your internal network should go outbound to an unknown server on the Internet. In Zero Trust, there’s no concept of unknown traffic. If it is unknown, it should be blocked automatically by default. This is the problem. By allowing all outbound traffic, you’re allowing malware to call out to their command and control networks. If you kill command and control, you’re going to kill all this ransomware.”

Ref. DCFE-D

“Everyone wants to know what product to buy to do Zero Trust or to eliminate ransomware. The truth is that you won’t know the answer to that until you’ve gone through the process. Which brings us to the third step in the methodology: architecting our Zero Trust environment. What protections do you have so far?”

Ref. A827-E

Aaron chuckled. “A lot of organizations limit access to sensitive servers by IP address so that you can only connect to a server from some secret server admin’s desktop. But this isn’t Zero Trust. It turns out in practice that attackers are very good at figuring out where those holes are. I’d prefer making a rule based on your role in the organization. Brent, is that something you can help with?” Aaron asked. Brent nodded and pointed out the correct role name for the training team to Harmony.

Ref. 60CE-F

“I’ve heard some companies hire enterprise architects to do this for them?” Nigel asked. “Enterprise architecture is a key part of an organization’s Zero Trust strategy,” Aaron confirmed. “They’re the group that needs to carry the torch for Zero Trust. They’re also the ones that have to do all the care and feeding.” “Cool, so when do we hire these enterprise architects?” Brent asked. “Oh, I thought you knew.” Aaron laughed. “You guys are the enterprise architecture group. Congratulations. There are a lot of ways to do enterprise architecture. But you don’t have to hire someone with the title of architect to do it. Having a cross-organizational team helps eliminate silos and provides much-needed perspective.”

Ref. 0854-G

“The fourth step is to create your Zero Trust policies. I know you’re not all firewall administrators, but it’s not just about firewall policy. Think about the who, what, where, when, and why. This comes from a Rudyard Kipling poem written in 1902,” Aaron said, pointing to the screen: I have six honest serving men They taught me all I knew I call them What and Where and When And How and Why and Who “So you are Kipling’s six honest serving men. Excuse me, ladies. Three men and three women. All these ‘Ws’ and ‘Hs’ are layer seven replacements for an old protocol, source IP, destination IP address, rule set. Here is how I break

Ref. A215-H

“Does that mean that my team needs to monitor the site? Or does someone else do that part?” Rose asked. “SharePoint and other services like it are a challenge to secure because it’s the users themselves who are allowed to share files with other people,” Aaron explained. “For a larger SharePoint site that is hosted online, you should consider looking at a cloud access security broker, or CASB, that has some data leakage protection or DLP capabilities. That’s just a fancy way of saying you can use a proxy or endpoint agent to monitor for when people upload files with credit card numbers, for example. But some of those tools will also tell you when a file or folder is shared with the public. In this case, let’s just look at who has access manually.”

Ref. 77F4-I

Key Takeaways To be successful at anything, and especially in cybersecurity, you need a strategy to achieve your goals. In cybersecurity, the goal is to avoid being breached. Zero Trust is that strategy for success. But what makes a successful strategy? A strategy is a plan to achieve your goals. But you also need to know when you’re making progress toward your goals, which is why the best strategies are measurable. There are a number of concepts in cybersecurity that sound like strategies but actually aren’t: Defense in depth—Often, defense in depth is compared to an onion; it has multiple layers. But how many layers do you need before you’re secure? In this way, defense in depth fails as a strategy because it’s not measurable. Compliance—Many businesses are required to be in compliance with many different compliance frameworks. Although being compliant may be measurable, the goal isn’t to be secure. Compliance is often a minimum starting place that regulators can agree on, but the unique needs of each business require a more tailored approach. Best of breed—Best of breed versus platform is more of a philosophical debate about the effectiveness of tools. The goal of this approach isn’t to prevent a breach; it’s to find the best vendors. The Four Zero Trust Design Principles The first and most important principle of your Zero Trust strategy is to ensure that you understand how the business makes money and what the organization hopes to achieve. Zero Trust should align with business outcomes, not prevent the business from operating effectively. There are a huge number of tools or products available to help you along in your Zero Trust journey, but it’s important to always keep these four principles in mind to stay focused on the big picture: Focus on business outcomes. Design from the inside out. Determine who/what needs access. Inspect and log all traffic. The Five-Step Zero Trust Design Methodology To make your Zero Trust journey achievable, you need a repeatable process to follow. The first step is to break down your environment into smaller pieces that you need to protect. Many organizations focus on reducing the scope of their attack surface. An attack surface is all the possible points of attack a threat actor could leverage to access a system and steal or exfiltrate data. In practice, the attack surface for a global organization with users working remotely could encompass the whole world. Rather than focusing on your “attack surface,” which is huge and hard for you to control, the Zero Trust design methodology focuses on what you can control: protect surfaces. Each protect surface helps you limit the blast radius of any attack to just that portion of your environment by doing the following five steps: Define the protect surface. Map the transaction flows. Architect a Zero Trust environment. Create Zero Trust policies. Monitor and maintain. The Zero Trust Implementation Curve When beginning your Zero Trust journey, you’ll need to start by…

Ref. A0C2-J

had started their meeting without him. Aaron was reviewing the five design principles with the team and had displayed the principles on the video wall: Define the protect surface. Map the transaction flows. Architect a Zero Trust environment. Create Zero Trust policies. Monitor and maintain.

Ref. DA79-K

admitted. “Physical security is the perfect analogy for Zero Trust,” Aaron said. “It’s easier to talk about since we’re not talking about imaginary invisible things. And I think people instinctively understand security. Security is a part of why we come together as a social animal: We come together for mutual protection. As much as we talk about how Zero Trust does away with the perimeter, it’s still important for us to have a foundation to talk about. So my first question for the group is where does physical security start?”

Ref. F4CB-L

it the doors to the building?” Brent asked. “What about the fence around the property?” Rose asked. “Or the camera system?” Harmony offered. “What about the security guards?” Nigel asked. “Anyone could hop the fence if there weren’t guards behind it.”

Ref. A3F5-M

guys are all talking about elements of perimeter security. That makes sense in the physical world where a human has to go through the perimeter to get inside a building. But that’s not the way things work in cyberspace. Ask yourself what would happen if someone invented a teleporter like in Star Trek. Those perimeter controls would still be important, but you’d need to shift the way you thought about security. The answer to this in Zero Trust is the protect surface.” “What does that mean? How do we change the perimeter?” Brent asked. “That’s the question we need to ask for every protect surface. So for physical security, we need to understand what it is that we’re protecting. Is it the life safety of the people in the building? Is it the servers in the data center? Is it the computers? Or the paper documents?” “Isn’t it all of the above?” Dylan asked. “Yes and no,” Aaron answered. “Again, physical security gives us another great analogy for Zero Trust. Inside the building, we create different areas where we allow anyone to roam freely. If you get access to the office areas, you can go to any one of the many cubicles. That’s an example of containment. If something bad were to happen, we have contained the blast radius of that damage to one area, but hopefully other areas are still safe. In this example, we place the…

Ref. 0E75-N

“Unfortunately, there’s this secondary attack surface. It’s called the internal network.” Aaron laughed at his own joke then continued. “When we research incidents, there’s this concept called dwell time. We want to know how long the threat actor was in your network before they were discovered. When you haven’t done any containment, the dwell times will be very long. Sometimes cybercriminals have been reported to have been inside a network for six months or a year before they are detected. For MarchFit’s physical security, you do have different areas and security checkpoints.…

Ref. 3278-O

Harmony folded her arms and leaned back in her chair. “So if I’m understanding you correctly, the idea with Zero Trust is that we move the controls away from the perimeter to the smaller protect surfaces. And that allows us to use much more…

Ref. AA0B-P

“Well said, Harmony,” Aaron said. “And those smaller protect surfaces allow us to change our policies more rapidly. If you had the president come for a visit, you might restrict access to certain areas where employees might normally be able to go, for example. We still have monitoring via closed-circuit television cameras that monitor the perimeter so we can alert on when things come in…

Ref. 42D5-Q

Unfortunately, Peter said, “if there’s not an infrastructure team that knows that they can push back and design the network with Zero Trust in mind, your physical security integrator will do what they can to get the computer up and running.”

Ref. 8C68-R

“This is one of the first lessons we need to take to heart when it comes to Zero Trust,” Aaron said. “When we think about transaction flows, we’re not just talking about how packets get from point A to point B. We also need to think about the business processes and relationships to give us the big picture. Let’s head back to the EBC to think about what controls we put in place to address the problems we’ve discovered.”

Ref. EB74-S

“The first thing I’d want to do is to move all the cameras and card readers onto private addresses. I also don’t think the cameras or the card readers need to be on the same network as other devices. We can put them all on separate non-routed networks so no one can get to them.” “That’s a great use of microsegmentation,” Aaron agreed. “What’s that?” Isabelle asked, turning her chair to face Aaron. “You’ve heard the phrase ‘never put your eggs in one basket’?” Aaron asked. She nodded and he continued, “Microsegmentation just means we’re putting different kinds of eggs in different baskets to keep them separate. What else would you guys want to do?” he asked, looking around the room “Maybe have different passwords for each camera,” Rose suggested. “That’s a good suggestion,” Aaron said, “but we also want to consider the complexity of managing all those different passwords. Do the guards need a password vault? Can the camera management company manage that? That’s a good transition to creating Zero Trust policies. MarchFit has some good policies in place for sponsoring visitors. And generally speaking we expect people to wear the badges in a visible place. What suggestions do you have for other areas?”

Ref. D2EC-T

“Right you are,” Aaron confirmed. “And when we talk about monitoring, we might consider additional alerting if someone unexpectedly comes in during one of those times.”

Ref. 6D1F-U

“For the monitor and maintain phase,” Dylan began, “if we had guards using unique logins, we’d have better audit trails when something changed.” “That’s definitely a best practice,” Peter added. “I’d also suggest sending physical security logs to the SIEM. You can use card swipes as behavioral triggers to help make determinations based on whether employees are in the office or working from home.” “Is there a way to integrate the camera system with the card reader system?” Rose asked. “That’s a great idea,” Peter said. “Why would we want to do that?” Brent asked. “I’ve seen it done before,” Peter said. “When someone swipes their card, their picture pops up on the video screen so the guard can verify that it really is the person in the video. Not every video system is compatible, so we’d have to check to see if there’s an API between the two systems.”

Ref. 4449-V

Key Takeaways You can’t have cybersecurity without physical security. If a threat actor can walk into your data center, it’s game over. With today’s card readers and video surveillance systems, however, you can’t have physical security without cybersecurity. Cybersecurity controls for physical security systems are often overlooked. Often, these controls are installed by third-party integrators as a part of a new building construction or when a company moves into a commercial real estate space. Many times, a different third-party security guard company will be in charge of using that system day to day. When so many different groups are involved with a system, it’s often difficult to secure because no one group is responsible for the security of that system. A big part of identifying a protect surface is understanding who has responsibility for that system. You don’t need to know how to pick a lock to get access to a secure facility. As mentioned in this chapter, some penetration testers will clone a badge using an inexpensive RFID cloner. Sometimes there are even easier ways like sliding a piece of paper under a door to trigger a motion sensor that automatically unlocks a door as a convenience to employees. Sometimes the building HVAC system creates too much air pressure in a room and doors don’t close properly. And sometimes, employees prop doors open for convenience. Physical security is the perfect analogy for Zero Trust. When designing physical security controls, we naturally place controls around the things we’re trying to protect. When organizations perform physical penetration testing, they are often surprised to discover the simple methods that criminals can use to get complete access to a facility. But because of the fault tolerance built into these systems, they can be a part of a learning protect surface without concerns about taking the whole system down. Several different transaction flows need to be mapped as a part of the card reader process. First, the process for a card reader processing a card swipe. Then there is the process for assigning credentials. Finally, there should be a separate process to help visitors get temporary access to company facilities. This chapter focused on the transaction flow mapping portion of the Zero Trust design methodology, and it’s important to note that there can be multiple transaction flows within a single protect surface. Some protect surfaces may include multiple applications, as the example in this chapter did with both card access and closed-circuit television (CCTV). Many organizations today employ proximity badges for employees so that they can just tap their badge on a reader rather than use a magnetic card swipe, although magnetic stripe readers are also still in use today. The identification information on a magnetic stripe card can be easily read so long as the card is swiped, so a threat actor needs to have physical possession to make a copy. However, RFID cards can be copied at a…

Ref. E289-W

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

Ref. B6FD-X

“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?”

Ref. 82F3-Y

“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.”

Ref. 8785-Z

“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.”

Ref. 49A5-A

“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.”

Ref. 205E-B

“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:

Ref. D205-C

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.”

Ref. FC71-D

“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:

Ref. 8305-E

“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.”

Ref. 2FFA-F

“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

Ref. EEE3-G

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.

Ref. F152-H

“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?”

Ref. CCB3-I

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.”

Ref. EFB1-J

“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.”

Ref. 1794-K

“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?”

Ref. 9A4F-L

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.”

Ref. 1B65-M

“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.”

Ref. BD97-N

“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?”

Ref. 028E-O

“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.”

Ref. 6484-P

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.

Ref. 887D-Q

“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.”

Ref. E5D8-R

“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.”

Ref. DF18-S

“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.”

Ref. 95C2-T

“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.

Ref. FECC-U

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.”

Ref. 4B9A-V

“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.”

Ref. CB5F-W

“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.”

Ref. CB0B-X

“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.”

Ref. ECD0-Y

“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.

Ref. C2CB-Z

“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.”

Ref. 11BD-A

“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.”

Ref. CB9E-B

“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.”

Ref. 1D2D-C

“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.”

Ref. 3651-D

“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.”

Ref. 9F8F-E

“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?”

Ref. F5EA-F

“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

Ref. 67DC-G

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.”

Ref. C0C4-H

“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.”

Ref. 97AD-I

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.

Ref. 800C-J

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.

Ref. 37BD-K

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

Ref. 0E21-L

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.

Ref. CE40-M

“Zero Trust doesn’t mean we shouldn’t trust people,” Dylan said. “We’re actually here to get to know more about you and your team. Tell me more about what makes your team successful.”

Ref. B746-N

“Okay. I can see that. I think Zero Trust is about getting rid of trust in digital systems. This means that we have to assume that we’re already breached. Like what if the bad guys have already put some malicious code in our systems? Ideally, Zero Trust should help us with that.” “Of course we want to write more secure code, but we’re also on a deadline to launch the new treadmills,” Boris said as he turned back to look at them directly, crossing his arms again. “There’s more hardware-specific code this time because the treadmills have to know what direction you’re traveling, but also how fast. One improvement we’re expecting later is for the texture of the treadmill to be able to change, like walking on sand or through snow. Or even being able to simulate slipping on ice.”

Ref. 7445-O

“Of course, we have to automate testing. That’s the cornerstone of DevOps,” Boris confirmed. “What if we put some automated security testing into the CI tool? We could do some light OWASP scanning to make sure that we weren’t introducing any delays.” “I don’t have any objections to this,” Boris said. “Maybe we could do some authentication testing as well. Make sure we’re searching for hard-coded data like IP addresses. We’ll be introducing some additional enhancements when we release Ben Richards later this month. We should be able to work it in by then,” Boris agreed. “Ben Richards? Isn’t that the name of the character Arnold Schwarzenegger played in the movie The Running Man?” Dylan asked. “I love that movie.”

Ref. 81BA-P

“I’ve heard that millions of API secret keys are leaked every year because developers wrote them directly into their code. Cybercriminals now scan public repositories and collect those API keys. So we need a way of storing and managing those secret keys that doesn’t involve sharing them via email.” “You seem like you might already have something in mind.” Boris grinned. “We should use a scanning tool to detect any API keys or other hard-coded data that’s stored in our repositories,” Nigel said. “We can use a secret manager to help manage our keys. Rather than hard-coding secrets in our docker ENV files, then sharing them over Slack or Teams, the secret manager will manage those permissions for us.” “Dylan,” Boris began, “I’m surprised you haven’t asked about our Kubernetes container orchestration system yet.” “What about Kubernetes?” Dylan asked. “I’m glad you asked. Kubernetes isn’t secure

Ref. EA8B-Q

“Yes, this is a lot of work,” Boris admitted. “But I actually feel much better about the new product launching now. Not to add more to our plate, but we purchased a tool last year to do runtime security, but we haven’t deployed it yet. Is that something you guys can help with?”

Ref. B81A-R

“We’ve looked at WAFs before,” Nigel said. “The problem was always that they were a proxy. They introduce another single point of failure if they aren’t already integrated into our load balancers. And if they aren’t integrated with our existing load balancers, then you have to have some manual process to sync certificates around. And the ones that are integrated with our on-premise load balancers won’t work with our cloud apps.”

Ref. 677C-S

What if we started thinking of security policies as code as well?”

Ref. E5E2-T

“Defining security policies in our code will help us scale up as we roll out features into our different testing and development environments before they go to production. And the security policy code will get checked into our code repositories so it can be versioned, and we can easily recover if something goes wrong.”

Ref. A30E-U

Nigel was on the edge of his chair now, talking rapidly. “We can define roles and permissions inside code. Enforcing least privilege and separation of duties in code will help keep our developers focused on writing code rather than explaining unique requirements to sysadmins. And it can be audited much more easily since the configurations will be centrally stored rather than being spread across a bunch of different systems.”

Ref. EACA-V

“One of the things that we are looking for is opportunities to seamlessly inject reauthentications into the process,” Dylan said. “Could we also require a new MFA when someone needs to do something major, like pushing new code out?” “Yes. We can enforce a lot of things in our security policies, like time-of-day access, restricting IP addresses, or requiring SSL connections,” Nigel said.

Ref. D6F5-W

Although Zero Trust doesn’t explicitly address techniques to write more secure code, removing the trust relationships around the development process can go a long way toward improving security. Even just removing secrets from being stored in the code directly—like IP addresses, API keys, or passwords—can go a long way toward containing any intrusions. And by integrating with identity services, developer permissions can be limited to only those necessary, further limiting the blast radius of any intrusions.

Ref. B42E-X

After a former NSA hacker publicly announced a zero-day vulnerability in Zoom at the beginning of the pandemic in 2020, the company shifted and was able to issue a patch within 24 hours in part because Zoom uses a DevOps development model. DevOps can help improve security rapidly, but the organization needs to be looking for security flaws continuously. Static and dynamic code analysis should be done on a regular basis for all code. Organizations should also host bug bounty programs to help monitor for potential issues and provide the security community with a well-known reporting path for issues.

Ref. 7A38-Y

“From my perspective,” Chris said, “we don’t have a detection problem in the SOC. We have a response problem. Our whole model is designed around providing as much detection as possible, logging everything, but it’s up to someone else to figure out whether it matters. We don’t have parsers built for all the new application-specific logs we’re getting from you now, for example. We need to understand Zero Trust more from you. I like the idea of building a SOC around Zero

Ref. A5F5-Z

“We’ve got a basic partnership today, sending tickets that MarchFit has to respond to,” Chris began. “But to be successful, we need to be involved with incident response as well, and we can help automate the response.” “Wait, will this cost more?” Dylan asked. “We’re still developing our managed response service, but I think if we can do this right, it should actually reduce the costs of the service because it takes less effort. With our playbook, we have automated responses already developed for the known bad things out there. Usually the known bad things out there can be blocked. It’s the unknown malicious activity we need to respond to. But what gets in the way is all of the noise. The false positives. If we can eliminate 99 percent of all the false positives, then what’s left will be much easier to investigate and act upon. But we need to be aligned with what you’re doing on Project Zero Trust to make sure we’re keeping

Ref. 2134-A

“We have several lines of business,” Dylan said. “We have our retail outlets. But we also have our network of content creators that people love taking walks or runs with. And then there is our new product development that is launching a new product in a few months.” “I think we can better align with MarchFit’s Zero Trust implementation by customizing our runbooks around those different lines of business,” Chris offered. “I bet that each of those different lines of business rely on different business-critical applications, and we can tailor our monitoring to more closely mirror that first design principle. What about being inside out?”

Ref. DBED-B

“We’ve recently built our own security orchestration system to help automate the runbook actions that we’re able to take,” Chris said. “To be successful at this, we’d need to be able to integrate with your identity system. We use our orchestration platform to help establish behavioral norms. A behavior that’s normal in one region or one department might be a critical alert if it’s discovered in a different region or department. That’s our secret sauce.”

Ref. 7846-C

only way that we can scale is for the SOC to be the nerve center of security. Your logs will provide the baseline. We’ll also need to have API access to your inventory and vulnerability management systems in order to enrich this data so that we know in real time as the transaction flows change over time or when devices are patched or updated. Just like Shift Left philosophy has led developers to get involved earlier in the process, we’ve applied the Shift Left approach to our SOC. The goal will be to move people like Jefferson away from simply looking through logs and alerts to writing scripts and building new orchestrations.” “Is there a way that you can be involved in architecture?” Dylan asked.

Ref. 9588-D

“We use MITRE’s ATT&CK framework to help provide context to our analysts on what a particular action means in a given situation,” Chris said. “The ATT&CK framework helps provide context to why a particular action is being taken and helps predict what actions might come next. There is actually a finite list of threat actors out there, and many of them use similar tactics, techniques, and practices, or TTPs. Just like one of your engineers might be an expert on a particular Microsoft product, so too attackers become familiar with a small set of techniques and they’ll try to leverage those skills against the same vulnerabilities over and over again.”

Ref. A451-E

“Didn’t Aaron say that Zero Trust is about containing breaches?” Dylan nodded. “Everything we’ve done so far has contained the breach to a specific protect surface,” he said. “I agree that we need to have continuous improvement, but I don’t know if we’re really aligning with Zero Trust principles here.”

Ref. 4646-F

“If I’m understanding you correctly, containment doesn’t just happen in a protect surface. What we’re doing in our SOC is helping to reduce the time that an attacker is inside your network. We know that this dwell time in some instances can be hundreds of days. If we can contain an attack in terms of duration, then aren’t we still on the right track with Zero Trust?” “That makes sense,” Dylan admitted.

Ref. 42BD-G

“Sometimes we’ll send alerts when we see a server stop sending logs,” Jefferson said. “A silent log source could mean the server has crashed or has been compromised and you might not know about it.”

Ref. DFBF-H

“There are other examples as well,” Chris added. “Jefferson’s point about blind spots can also extend to cloud logging where you may not have the same visibility. Having a cloud access security broker, or CASB, can give you a similar increase in visibility. We also offer penetration testing, for example. Whether you use us for penetration testing or whether you have another vendor for that, I think we should share the results of the test with our SOC to help understand the environment. Same thing with your regular vulnerability scans. We can enrich our inventory and provide more customized runbooks for you.”

Ref. D97A-I

“You mentioned that you have an orchestration system,” Dylan said. “How does that part work?” “We know it takes several minutes for even the best-trained analysts to review an alert and decide how to respond. With the volume of attacks that are happening, we want to reduce response time down to seconds. We know the attackers have automated their attacks, so the only way to keep up is to have a machine respond in real time,” Chris said. “What happens if we accidentally disable an important service with an automated rule?” Noor asked.

Ref. F972-J

“That brings up another issue,” Harmony said. “I’ve been on our monthly SOC briefings in the past and I think we can step up our game when it comes to reporting. Is there a way we can measure how effective we are at containment? We don’t want reporting that says you responded to tickets within five minutes or how many cases you opened. That doesn’t tell us that we’re more secure or more effective. If we’re going to have a Zero Trust SOC, we want to report on how many false positives we’ve reduced. I’d like to know many new rules you have added to your runbook and how many of them have been applied in our environment. How does that compare to the previous month? And how does it compare to the same time the previous year since we may have seasonal changes. Does it look like attacks are advancing through the MITRE ATT&CK framework and are we being successful at disrupting the later stages like command and control?”

Ref. 5ED7-K

“The SOC is another protect surface,” Aaron said. “You need to incorporate Zero Trust into the incident response process itself. The incident response process is the main way that you’ll interact with a SOC.” “Really?” Dylan asked. “You think we can do Zero Trust in the incident response process?” “I definitely think Zero Trust applies to the incident response process. Managed Security Service Providers are a critical partner, but they’re a huge target for attackers because they have connectivity inside the most sensitive parts of hundreds or thousands of customer networks. This is true for any IT service. Two-thirds of breaches come from your vendors. If you haven’t started looking at third-party vendor management, you might add that to the list, particularly for cloud service providers.”

Ref. 5D2C-L

The other NIST security control publications like Special Publication 800-53 for government entities or 800-171 for nongovernment entities or even ISO 27001 or the CSC top twenty controls can all be mapped to the five-step framework.”

Ref. 022C-M

“We based our incident response plan on the NIST SP 800-61,” Harmony said to Brent as she pointed to the screen. “It goes into more detail on the final three steps of the Cybersecurity Framework. It’s a little older than the Cybersecurity Framework, so it uses some slightly different terminology. But NIST makes standards for everything. They’ve been around for a hundred years.”

Ref. A1E4-N

“In the incident response process, what we’re talking about is the containment, eradication, and recovery stage,” Luis responded. “We’d need to consider several factors, including potential damage that could be caused or whether theft of data is likely to occur. Do we need to preserve any evidence? Would taking down a system impact a critical service? Do we have the time and resources to respond adequately? Do we need full containment? Or will partial containment be enough? And are we implementing an emergency workaround? Because sometimes emergency workarounds end up being there for years afterward.”

Ref. 3DD2-O

As Chris indicated, the SOC doesn’t have a problem detecting issues; they have a response problem. How do you separate out all the noise and false positives and end up with actionable information that allows you to respond to a threat actor in real time? This takes very mature playbooks, teams of well-trained threat hunters, and automation capabilities. But it also takes the insights and lessons learned from monitoring attackers and the tactics, techniques, and procedures (TTPs) they leverage against not just from a single company but from hundreds or thousands of other organizations.

Ref. 5014-P

“I’ve been wondering about that,” Isabelle said. “I don’t think the cloud is a protect surface.” “What do you mean?” Dylan asked. “It’s a lot of different protect surfaces. Like you said, they all have similar issues that we need to address. I took all the different projects we’ve worked on over the last couple years. There would have been a lot of opportunities for us to review security best practices at the beginning of a project. Where do you want me to start?”

Ref. 61F6-Q

“We always want to be careful. I know our content creators who film themselves taking walks through parks or on beaches upload videos to Vimeo for our production staff to approve before going into production. But I happen to know of cases where one of our most famous creators likes to upload them to YouTube or Twitch where they have other followers, so we wouldn’t want to break a business process without understanding the business first. That’s the first principle of Zero Trust. But there were other apps being used, like free online PDF converters, which made me start thinking about shadow IT. I started thinking about whether there was another way of tracking down some of those other apps.”

Ref. 0FD9-R

“Software-defined perimeter?” Dylan asked. “Yes. SDP for short,” Aaron confirmed. “I thought the whole point of Zero Trust was to get rid of the perimeter concept?” Dylan asked. “Well, yes, you got me there. I wasn’t the marketing guy who thought up the acronym, though. You ran across the concept already, inside NIST 800-207. It was called a policy engine. Here, let me text you a picture of what I mean.” Dylan switched to speakerphone and opened the picture. “The policy enforcement point, in this case, is just an agent on the client that connects back to the policy engine to allow or deny activity based on that employee’s role,” Aaron explained.

Ref. 1A28-S

“What happened to inside-out design?” Dylan asked. “You did start from the inside. Now you’re working your way out to the edge,” Aaron answered. “But you’re right—there is one thing you’re missing. You’re using a lot of APIs. Are those another protect surface? Or are they another control?” “This is another one of your trick questions, isn’t it?” Dylan said. “Is it?” Aaron asked. “It’s both, of course,” Dylan said confidently. “We need to remove trust relationships from APIs, don’t we?” “Unfortunately, you’re going to need another tool for that. Vic won’t like it. But you can make the case. Just like you need a WAF to protect against the OWASP top 10, OWASP has a separate top 10 for API vulnerabilities. It’s possible your APIs could be exposed, leaking sensitive info with no audit trail,” Aaron said. “Just be sure and let him know that you don’t have to have a product. He can always ask each application administrator to manually review account activity daily. That’s a bigger cost in the long run, but at least you’re speaking his language at that point.” “So I’m right. It is both,” Dylan said.

Ref. 95A0-T

“Yes,” Aaron said reluctantly. “They’re a protect surface in that you probably have an API gateway in your service catalog. But with SASE and API security, you’ll start to be able to provide more actionable data when it comes to protecting your cloud infrastructure.” “Where do we start?” Dylan asked.

Ref. 1601-U

“Same place we always start,” Aaron said. “You need an inventory. We need to be able to capture all API traffic with a discovery scan. But we also need to be able to continuously discover new APIs when they’re created as well. We need to be able to understand the APIs to be able to detect bad behavior. And the SOC needs to be able to investigate and respond to API threats. You’ll need to be able to retain API data for a long time to be able to do historical threat hunting.” “Is that all?” Dylan laughed. “We’ve got plenty of time for all that before the launch.”

Ref. 89DC-V

that position, but I had forgotten about it after the ransomware incident,” Boris admitted. “I almost did too,” Dylan said. “We didn’t talk about secure container configurations. Those are the standards I was thinking about.” “Sure, we can add some configuration checks,” Boris confirmed. “Can we do a negative check?” Dylan wondered. “Make sure something isn’t there?” “Of course. This is something we already do,” Boris said. “We need to make sure we aren’t running the container over a TCP socket. It needs to run as a Unix socket. Can you create a rule to fail the test if it sees a specific command?” Dylan asked. “Yes. This is easy if you give us the specific command,” Boris said. “I’ll get you guys a list. We should also make sure containers aren’t being run in privileged mode and not allow any escalations of privilege.” “Oh, cool,” Boris said, impressed. “I didn’t know there was a command to prevent escalations of privilege. I wish other software had this option.” “We should also create limits on the size of the container and the amount of memory it can use so the containers don’t grow out of control,” Dylan said. “Also, we should make sure containers can’t communicate between each other. And definitely make sure the filesystem is set to read only to prevent any modifications.” “I had no idea this is why you were here,” Boris said. “Some of us are going to happy hour down the street. You want to tag along?”

Ref. 496E-W

“Yeah. That sounds cool,” Dylan said, walking with Boris. “And remind me about container images. We can’t just trust that OS images from a third party are secure. We should find a way to automate validation of images,” he said as they walked out of the building.

Ref. 0F1B-X

In the early days of the Internet, to deploy a new application you had to first build a server, install and harden an operating system, deploy controls like antivirus, set up the server for logging, and then tailor firewall rules to lock down an application. For some organizations, this process could take weeks or sometimes months, and each step required knowledgeable staff trained on each component of the process. One of the primary reasons that organizations deploy applications or services to the cloud today is scalability. It can take seconds to deploy a new application in some cases with containers. And cloud service providers have created self-service management portals that allow a single administrator to deploy new services at the push of a button. But this also requires cloud administrators to be familiar not just with one aspect of security, like a firewall, but with all aspects of security to ensure that applications are deployed securely by default. Adding to this complexity is the fact that many organizations must deploy applications not just to one cloud provider but to many different cloud service providers.

Ref. 23CF-Y

There are a number of very common issues when it comes to cloud security, like having open cloud storage, not having secure default privileges, not enabling MFA, and not enabling sending logs to the SOC, to name just a few. One of the best ways to help defend all the various cloud protect surfaces is to have robust security requirements built into the project management process itself. This should help address much of the officially sanctioned software at an organization, but it may not capture all shadow IT.

Ref. BF4E-Z

cloud access security broker (CASB) can be deployed in several ways to help provide this visibility. Some organizations choose to operate a CASB as a proxy that can help provide this visibility but may add some latency to applications. CASBs may also require significant customization to provide enough detail into how an application is being used, and when an application is updated it may break the CASB’s customization. Alternatively, some vendors provide APIs into their cloud applications. For many common applications like OneDrive, SharePoint, Box, or SalesForce, CASBs have native integrations that allow you to quickly gain visibility to the application.

Ref. 6F39-A

While the focus of Zero Trust starts from the core of your business and works its way out, you also need to understand the importance of endpoints in your environment. Secure Access Service Edge (SASE) products offer a way of achieving Zero Trust in different environments by allowing an organization to create a software-defined perimeter (SDP). Many organizations have moved to a more flexible model where users work from home, and SDP enables you to ensure that endpoints communicate only with the servers or services that have been approved by policy. In NIST Zero Trust terms, 800-207 creates a conceptual “policy engine,” which is integrated with an identity provider and only approved services are allowed. This effectively prevents malware from spreading to SASE-protected endpoints [“via”] lateral movement. SASE-protected endpoints can also be further protected from visiting malicious websites through remote browser isolation so that web pages are run in a sandbox environment, not on the endpoint itself.

Ref. 1847-B

One of the biggest blind spots today when it comes to cloud deployments is all of the APIs that interconnect different services. While MarchFit has a WAF and other security controls on the user front end to protect against OWASP top ten attacks like SQL injection or cross-site scripting, there is little visibility on the back end of these web services. The OWASP top ten API vulnerabilities include issues like broken object-level authentication, excessive data exposure, or mass assignment. These vulnerabilities led companies like Peloton, Parler, Facebook, and others to leak vast amounts of data. Even when…

Ref. 5772-C

The last phase of the Zero Trust design methodology reminds us to monitor and maintain our cloud protect surfaces. Monitoring API traffic is a great way to gain the same level of visibility into cloud services that many organizations were able to achieve for applications that were on premises. All API calls should be logged for at least a year, similar to how other logs are stored for investigative purposes. An API inventory should be maintained just like other device or data inventories, but because…

Ref. A92D-D

Today, most organizations rely on their SaaS partners to deliver services securely. A cloud service provider is just another third-party vendor, and one of the main protections organizations can use to protect themselves from third parties are contracts. You should have a third-party vendor management program to help address the risks here. Contracts should include specific requirements around notifying you when an incident has occurred (not just breaches). Contract language shouldn’t include any limitations of liability for direct damages. Many vendors limit damages to the fees paid for a service, but when personal or other sensitive information is shared with users, the costs to an organization could be significant. Contract provisions should require vendors to have cyber insurance, particularly since two-thirds of all breaches are caused by vendors. Vendors should be required to pay the costs of notifying victims. Every company is responsible for doing due diligence of vetting the security of their vendors. There are some organizations like Shared Assessments and the Cloud Security Alliance that help provide clarity into the security posture of many vendors. Alternatively, some organizations choose to create their own security questionnaires based on their specific needs. In some cases for extremely large, high-risk vendor contracts, organizations may require evidence of security audits or even conduct their own audits of vendor security. There are also several vendors that provide security ratings services, similar to…

Ref. B4CB-E

more laughs. “I was skeptical at first about Zero Trust. But now that we’ve been doing it, I can say that we’ve made one of the best strategic decisions we could have made. That’s what Zero Trust is—a strategy for aligning security and the business.” Dylan paused,

Ref. 5067-F

“The focus of Project Zero Trust has been to contain a breach or other incident to the smallest impact possible. After careful analysis of these projects, we’ve shown how we can reduce the time it will take to recover from an incident from a minimum of thirty-six hours down to eight hours.”

Ref. 8332-G

“I love that idea. We can have you work with our product marketing team to have you speak at some conferences. I want you to share the whole story, both the good and the bad. We need to rebuild trust with our clients. What else can we do to show our commitment?”

Ref. 2347-H

“What are you talking about?” Rose said. “Of course I applied the Zero Trust methodology to security awareness. The protect surface is people. The transaction flow is the life cycle of the employee from the interview process to the day they leave the company or retire. Sorry, I thought this was obvious.” “No, go on!” Dylan exclaimed.

Ref. 26F6-I

“Like we talked about in the beginning, it’s more effective to secure something at the beginning, so we start with new hire orientation. But then we’re rebuilding all of our IT or HR training to intentionally include elements of cybersecurity, from learning Excel to how to be a good manager. Creating policy is all about customizing the user’s experience, so we offer several different tracks for security-specific training as well, based on different roles in the organization. Do you want to see our training plan?”

Ref. 790B-J

“There are two other things that you should know in general before we dive in further. First, we should never trust that our tools are completely secure. And second, we should plan for things to go wrong. You guys probably know this already, but we never share passwords on Slack or Teams. Because we don’t trust these systems, we don’t want to put sensitive info out there that could be exposed. We have other secure systems for sharing sensitive data.”

Ref. 0CA7-K

“And we’ll be extra prepared by having done this already,” Rose said. “But the first thing we’re going to do is what we call a premortem. Most people wait till the end of a project to think about what went wrong. We’re going to flip that and talk about what might go wrong. Then we’ll talk about what we’re going to do about it. And then plan for it.”

Ref. D074-L

“Part of the monitor and maintain phase means that we need to be regularly evaluating whether our controls are good enough or whether we have any blind spots,” Dylan answered. “A tabletop exercise is a great way of doing that.”

Ref. 11B8-M

“Trust me—there are always more trusts that you can remove.” Chris laughed for a second, but then he became serious. “I don’t know this for sure, but I get the impression that some people think of a penetration test as a kind of CYA. They hope that the tests will show that they don’t have any issues or to show off how good the security team is. One of the reasons that I started my company was that I didn’t feel like I was getting our money’s worth doing a penetration test unless we found something to help make us better. The goal is to always be getting better.”

Ref. BFAA-N

Chris laughed. “In tabletop exercises, we call it an MSEL, or Master Scenario Events List. The MSEL comes from the NIST standard for developing and running tabletop exercises. It’s NIST 800-84 if you want to look it up. But first we need to start with defining our objectives. Those might change based on the audience, but in our case I think we should go with a mix of technical and procedural objectives.”

Ref. 6797-O

“One of the things that I was concerned about are false positives,” Harmony said. “We’re always getting notifications from the SOC that sound really scary. Sometimes we have to drop everything to investigate, and it turns out to be a server we didn’t know about talking to a new service no one ever heard of. But both are legit.” “That’s definitely something we love testing in a tabletop,” Chris said. “We always want to include red herrings into the scenario to simulate the confusion that can happen in a real incident. We will include some red herrings into the scenario, but for the MSEL, we’ll ask whether the team can tell the difference between a real issue and a false positive.”

Ref. 62DB-P

Any questions before we start?” Chris paused and looked around the room. “Hearing none. It’s 8:35 a.m.,” Chris began. “The manager of the customer support hotline emails Noor that several customers report that their TreadMarch units appear to start but are only displaying a blue screen and will not connect to the network. What do you do?”

Ref. 2B2E-Q

Everyone in the room turned to Noor. “It’s probably too soon to panic,” she said, which got a huge laugh from the room. “I’d ask the manager for more information about the devices. Is there a common denominator like the locations, firmware, or age of the devices? I’d also want to look at our change control to see if we had made any recent changes.” “Is there someone we can dispatch to physically go out to see one of the treadmills?” Vic asked. “Yes, we can dispatch a local third-party technician. They are probably already working on other support tickets, so we’d need to pull them off a job and reroute.” “How long would it take to dispatch a technician?” Chris asked. “Probably thirty minutes, best case,” Noor answered. “Maybe forty-five with traffic.” “Noted,” Chris said. “The technician will provide a report at 9:30. What other information will you need?” He typed several notes into the MSEL guide for the debrief after the tabletop. “Boris, have you ever seen an error like this before?” Dylan asked.

Ref. 9FA1-R

“Don’t we have a monitoring center where we can see the status of all our treadmills?” Vic asked. “We don’t have a real-time view,” Boris said, scratching his head. “We run daily reports on activity and usage, but we’ve never put together a dashboard where we could do this live. We could probably pull something together in about a week.”

Ref. 9F24-S

“What do you mean by suspicious?” Harmony asked. “Our behavioral-based detections indicate that the activities were out of the ordinary for those users,” Luis explained into the camera, his face lit by his computer monitors. “We can provide you the ID numbers of those users, but I don’t have any further information at this time.”

Ref. F19A-T

issue,” Noor said, adjusting her tie so that it was straight. “The challenge is knowing when something is systemic. For a single device, that’s low priority and our help desk will resolve it. Our incident response plan says that if we reach a threshold of 1 percent of our devices, we raise the issue to a medium-level category, and we’ll respond by forming the incident response team. If it’s more than 10 percent of devices, that’s a high-level event. In practice, all events start out as a low-level notice, and as we investigate the event will go up in priority.”

Ref. 4359-U

“Let’s take the server off the network asap,” Dylan said. “I think we’re officially in a high-severity incident. We should send notifications to all IT staff to be on alert. They should review their logs and log off any remote users they can identify. We should bring in our incident response partner.”

Ref. E290-V

“It’s possible someone had written things on a whiteboard. The drone could have seen passwords or product specifications.” Rose shrugged. The group broke into several smaller conversations as people speculated what data could have been observed by a drone looking into the building.

Ref. 165E-W

“How do we know what data could have been stolen?” Kim asked. Kofi spoke up for the first time. “We definitely need to know what data was stolen to decide what to do next. We might need to do victim notifications or file a report with the SEC depending on what the answer to that is. How do we tell?”

Ref. E9D4-X

“No,” Kofi interrupted. “We don’t have enough evidence yet to know that there has been a breach. We aren’t required to notify unless there is a breach. And the legal definition of a breach is when data is lost. We aren’t required to notify anyone yet.”

Ref. 00BD-Y

“I recommend that you consider using a memory-safe IoT programming language like Rust,” Peter said. “IoT devices typically don’t have a lot of horsepower, so they’re very susceptible to buffer overflows, for example. From the other penetration testers that I’ve talked to, this has had a huge impact for their other clients. It’s almost eliminated all the most common ways we exploit IoT devices.”

Ref. 0B5F-Z

“Segmentation isn’t really a great option for scanners since they need to be able to talk to everything,” Peter said. “When you’re using credentialed scans, you don’t need all those ports open, so you can just lock them down. But if you’re doing uncredentialed scans, only keep those firewall rules open when you’re running the scan and remove them when you’re done. Or set those rules to only apply during a specific schedule during the week.”

Ref. FAD0-A

Like most things in cybersecurity, the model for how to conduct a successful tabletop exercise can be found in a NIST Standard.

Ref. 51E6-B

The first method that the penetration tester used to get into the MarchFit network was to exploit the trust relationship that the company had with their own treadmills. The treadmills are an example of an Internet of Things (IoT) device, and cybercriminals will commonly compromise these types of devices because they don’t have all of the protections that other devices may have. Once the tester took over a treadmill, they got access to an internal update server in the MarchFit network and were able to move laterally from there.

Ref. E529-C

The other trust relationship that the penetration tester chose to exploit was in the security team’s tools. Many organizations use vulnerability scanners to identify devices that are vulnerable to attack. There are two types of scans that these devices will run. The first is a port scan for each target that is used to probe what applications might be installed on a device, to fingerprint what operating system is running, and to determine if those match any known vulnerabilities. The other type of scan, a credentialed scan, uses real usernames and passwords to log in to a device to directly check what software is running. The credentialed scan yields much more accurate results, but many organizations will open holes in firewalls for these scanners to talk to everything in the network no matter what kind of scan is being run. In effect, this means that a vulnerability scanning server is highly trusted, which makes it an attractive target for attack.

Ref. 2914-D

Experts call this phenomena the fog of war. Our brains will naturally start to connect the dots to draw conclusions, but often we don’t have all the information we need to create a clear picture. The best way to combat the fog of war is to communicate, ask questions, be transparent, but most of all, don’t stick with your conclusions when you receive new information.

Ref. 6AE7-E

Zero Trust implementation because we can look for potential opportunities to remove trust from digital systems.

Ref. 154F-F

“It seems like I may have forgotten to mention the Zero Trust Maturity Model,” Aaron said apologetically.

Ref. 53D0-G

“I like using the transaction flow matrix chart that John Kindervag developed to help show how protect surface policies are developed to talk internally. Here, let me share my screen.”

Ref. 1408-H

“The transaction flow matrix can help you understand how each of the different protect surfaces can potentially impact one another. As you think about the maturity of your protect surfaces, you’ll need to think about how the blast radius from a compromise in one might impact the other protect surfaces.”

Ref. 2274-I

“Exactly,” Aaron confirmed. “But you only have so many IT resources. So if you had ten team members and eight of them are tied up working on firewall rules because of all the complexity of your rules, then you might be sacrificing control over identities or visibility into logs, for example.”

Ref. 53EF-J

“Not many organizations have complete testing infrastructures where they can detonate malware and test whether all their controls are adequate,” Aaron explained. “BAS or emulation software helps do this kind of testing in more of a real-time way than doing an extended security assessment or penetration test. I think it’s most beneficial for more mature organizations. Breach and attack simulation can simulate how a real attacker might attempt to attack an organization using predefined attack paths. With emulation, the tools help customize how attacks are launched, using threat intelligence to contextualize how the business actually works.”

Ref. 337B-K

“The MITRE ATT&CK Framework provides an analysis of all the TTPs of attacker behavior so that defenders can better understand and defend against those TTPs,” Aaron explained. “The Engage Matrix is a framework for defenders to help them to provide an active defense against attackers. The idea isn’t to just passively defend, it is to proactively engage attackers to bring the fight to them.”

Ref. EFF8-L

“The first principle of Zero Trust is to remove all trust relationships from digital systems,” Aaron said. “With the Engage Matrix, we build profiles of threat actors that target us, and carefully expose specific resources that act like breadcrumbs that lead the attacker toward lures or honeypots. The next phase is to expose what the attackers are after with those breadcrumbs.

Ref. 76A0-M

When I started my own Zero Trust journey, I didn’t take into account whether I’d be able to scale our implementation of microsegmentation and other controls along with the size of the team that I had at the time. We were extremely granular in our controls in order to contain the blast radius of any incident. But because we didn’t start with the concept of protect surfaces, we applied the same level of focus and control everywhere. As a result, our controls became too complex to manage. I believe that John Kindervag’s Zero Trust Design Principles and Methodology can drastically reduce the complexity in your approach to Zero Trust.

Ref. 0754-N

organization. To know what applications are the crown jewels, you can look to this document. In addition, every organization needs to have a technology risk register to have a current list of the biggest threats to the business from a technology perspective. A risk register should include much more than vulnerabilities; it can document lack of capabilities in specific areas and identify single points of failure or weaknesses in the various controls that the organization has in place.

Ref. 7210-O

DevOps helps organizations deliver better software more quickly, and this development pipeline can include security testing that can ensure that trust relationships, like embedded passwords, emails, or IP addresses, are removed from code before being released into production.

Ref. 0ABD-P

Maintaining an internal 24x7 SOC is probably outside the capabilities of most organizations. Working with an MSSP service that can help tailor their monitoring to meet your business needs is crucial. But you also need an MSSP that can align with your own protect surfaces, incorporate data from penetration testing findings, and integrate with your specialized internal tools.

Ref. 2421-Q