Jefferson sat in front of his workstation bleary-eyed from having worked a double shift overnight. He was sitting in front of two curved monitors that almost wrapped around him. The left screen displayed a live stream of logs, filtered by a long search string that Jefferson had painstakingly spent the whole night creating, narrowing the search terms each time he understood a little more about what was going on. On the right screen, his ticket queue was displayed. The more tickets that came in, the more distracted he became. The day crew would start in a few minutes and would help, but he was a little worried his team lead would just dismiss what he had found.

Beyond his monitors was a wall of twelve eighty-inch screens. They showed the weather, news, views of customer networks with colors indicating when they were having issues, and the all-important queue of tickets coming in.

One of the graveyard-shift crew had called in sick. Jefferson didn't have to take the shift. He wasn't on call or anything. But then that would have meant letting go of what he had found. Someone else might not be able to see the pattern of anomalies he had discovered. It was more than just a pattern. He was sure there was coordination behind it.

The only other person on shift was Nadir. Nadir was wearing headphones, but Jefferson could still hear the hair metal music on his side of the room. Jefferson had made the mistake of referring to the music as glam rock at one point and had to listen to a three-hour explanation of the differences between them. As Jefferson was about to work up the courage to ask Nadir for his help, his team lead Luis arrived, several minutes early, carrying enough coffee for both shifts. He took a coffee for himself and set the rest down on the desk next to Jefferson, where everyone else would have to talk to Jefferson. Was that on purpose?

“Thanks for working last night, El Jefe,” Luis said, using his nickname for Jefferson. It had started to stick with the rest of the team. Jefferson had only worked in the SOC for a couple months, but somehow that nickname, more than anything else, made him feel like he had a future in cybersecurity. “How'd it go last night?” Luis asked.

Jefferson blinked the sleep out of his eyes, grabbed a coffee, and tried to figure out how to explain everything going through his mind. The coffee tasted like chocolate, with a hint of some nutty flavors he couldn't place. “I've spent the last sixteen hours looking at MarchFit's logs,” Jefferson blurted out as he began highlighting logs on his screen to show his findings. “I saw one machine call out to a remote address. The address wasn't on any threat lists, but it had been newly registered in DNS, so I dug a bit further. It was late, so I was pretty sure no one was actually using that computer. I didn't see any other devices connecting to that specific IP. But the fact that there were some low-severity PSExec logs really bothered me.”

“How big a problem do you think it is?”

Jefferson didn't know if he should say aloud what he was thinking. Maybe it was because he was so tired. Jefferson had pulled double shifts before and knew how easily confused he got when he hadn't gotten sleep. He blinked as the day-shift analysts came in joking with each other. He leaned in closely to Luis and whispered, “This is 3nc0r3. I know it. I don't know how much longer I can stay awake, but I gotta explain this to someone while I can still talk coherently.”

Luis took a long drink of his coffee and tossed the empty cup into the trash. “No problema, Jefe. I'm on it. You get the others up to speed and wait for Money, who will be coming directly.”

“You're sending in The Money?” Jefferson exclaimed. “That's all you had to say.”

Several minutes later, Harmony led Dylan down the stairs into MarchFit's basement. At the bottom was an old-style freight elevator with a sliding fence for a door. There were rows of chain link fencing around the basement making up storage areas for different departments. The lighting was terrible, but Dylan noticed cages full of treadmills, and cages full of returned merchandise, alongside cages full of old, clearly broken computer equipment. They turned right where a row of cages ended, dim light leaking in from a tiny window.

“How does the SOC know if a device has multiple IP addresses?” Dylan asked. “Do they think that those are two different devices? Or do they have a way of resolving those devices into a single entity?”

“They don't know,” Harmony answered. “They can see our DHCP logs, but we have to resolve devices in our inventory system after they alert us.”

“What about identities? Do they have a way of looking at a user and finding all the devices they've interacted with?” Dylan asked.

“Again, no.” Harmony pulled a chain and a row of incandescent bulbs started to blink on, illuminating the rest of the basement in a harsh white light. “We've got some tools internally that have this, but the SOC doesn't have access to them.”

“How do they know when one of our tools finds something potentially malicious?” Dylan asked.

“The tools send an alert to the SIEM, and they will see that in the logs,” Harmony said.

“But if they don't have access to our internal security tools, how can they do investigations into what is going on?” Dylan asked.

“They can't,” Harmony said.

“So all they can do is see an alert in our logging system, and the only thing they can do is tell us about it so we can go investigate ourselves?” Dylan stopped to look at some old servers that were stacked on a pallet wrapped in plastic like they were ready to be recycled. He was pleased to note that the hard drive bays had all been removed. Those must be somewhere else, hopefully being erased. He'd have to ask about that.

“Don't our tools have APIs that they can connect to?” Harmony suggested. “That could give them access to the data without giving them direct access to those systems. Would that accomplish the goal of having Zero Trust?”

“I've heard of some places that also monitor access to APIs. We should look into that soon,” Dylan said. “But you're right, I bet someday all logs will be sent over APIs.”

“This is us,” Harmony said, going through a rusted door into another darkened room. A sign written on a piece of torn poster board above the door read “Abandon All Trusts, Ye Who Enter.”

“Um, where are you taking me again?” Dylan asked as he entered. The only light came from numerous computer monitors around the room, haphazardly hung on the walls or arranged on the makeshift table in the center of the room made up of old doors that had been taken off their hinges. “This reminds me of a movie. Johnny Mnemonic, I think,” he said.

“That's exactly the look I was going for!” Harmony said, taking her spot in a chair that looked like it was salvaged from a racing car. “Sit next to me so we can both see their screen,” she said as she began the Zoom call. Dylan sat down in the chair next to her. It had also been salvaged from the junk pile, apparently. He looked around the room. There was a poster featuring the actor David Duchovny from X-Files across from them that read “Trust No One.” He had the distinct impression that he was in Harmony's personal man cave. Woman cave? Or was it a she-shed?

“Thanks for waiting, guys,” Harmony said. “Thought my new boss would want to hear what you had to say. What's up, Jefe, you look like crud. You been up all night?”

Jefferson and Luis were both on the Zoom, along with two other members of the SOC.

After several seconds, Jefferson realized they were talking to him. “You guys know what PSExec is? Right?” Not waiting for an answer, he continued, “It's this utility that lets you run commands remotely so long as File and Printer Sharing is enabled on your target and you have credentials on your target?”

“Right,” Harmony said.

Jefferson was talking rapidly between sips of coffee. “I had just finished this course on PowerShell, but we already have detections for that in our platform. So I started doing some threat hunting in our customer base to see if we saw any PSExec activity similar to what we would normally look for in PowerShell. And it turns out one of your machines was showing activity after the user had left for the day. The script was just dumping hardware info, so it didn't rise to a critical-level alert, but I knew Money would want to know about that kind of thing, so I kept looking at it.”

Dylan grabbed the mouse and muted the Zoom meeting. “Did that guy just call you Money?”

“Yeah, it's embarrassing,” Harmony said. “But it's kinda sweet, so I never said anything.”

“Do they even know your real name?” Dylan asked, noticing that she had changed her Zoom profile name to #Money.

“Probably?” she said. “Shush, this was just getting interesting,” she said and unmuted.

“Later on, I saw some EDR alerts for the same system that there were some blocked attempts to run a crypto mining installer. This didn't rise to the level of a critical alert because the attempt was blocked. But there were more until I saw that a cryptominer was successfully installed and we escalated. I think the bad guys were dumping hardware info to see what cryptominer would work best on that system before they actually installed it.”

“Where were the attempts coming from?” Dylan asked.

“This user was working from home and the requests were coming from another device on the local network.”

“Thanks, Jefe, ” Harmony said. “Dylan, what do you think the chances are for us to get Noor's approval to disable File and Printer Sharing?”

“I'll ask,” Dylan said, typing an instant message to Noor asking her to join the call. “But I'm wondering about whether our SOC is another protect surface we need to work on.”

“Boss, you might be on to something,” Harmony said.

Dylan noticed the Zoom alert at the top of the screen showing that Noor was requesting to enter the meeting. After getting Noor up to speed, she asked, “I assume we've removed the cryptominer?”

Luis nodded and said, “Yes. We sent a ticket to your help desk when we first reached out to Harmony and just got the response that the ticket has been closed.”

“Thank you all for your dedicated work. I love to see that kind of initiative,” Noor said. “But I'm a little worried about whether we can scale our response when we have so many users. How do we respond faster next time?”

“I think I can help with that,” said one of the other individuals from the SOC. “Sorry for not introducing myself earlier, I didn't want to interrupt our analyst while he was giving you the update. I'm Chris Grey, I'm the owner of the MSSP and I've been hearing a lot about your Zero Trust implementation and wanted to learn more. So it's good timing for a conversation.”

“What have you heard?” Dylan asked.

“We've seen the number of alerts start to go down dramatically over the last month or so from MarchFit. Which is really interesting, because at the same time the volume of logs you've been sending to us has gone way up,” Chris said.

“That is interesting,” Dylan said. “I know it's hard to detect some of these issues since you guys don't know everything about how the business functions. We need you to be more of a design partner for a Zero Trust focused service.”

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

“We'd love to hear your ideas,” Noor said.

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

“If we're going to start a Zero Trust partnership with the SOC,” Dylan said, “let's go back to basics. Harmony, can you pull up the design principles?”

Harmony shared her screen, showing the four Zero Trust design principles:

1. Focus on business outcomes.
2. Design from the inside out.
3. Determine who/what needs access.
4. Inspect and log all traffic.

“The first part of Zero Trust is about knowing the business,” Dylan explained. “How we make money, what the strategy is, and where the business plans to go.”

“So what does that mean for MarchFit?” Chris asked.

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

“That has defined our approach,” Dylan said. “We've prioritized working on our most business-critical protect surfaces first, and then expanded from there.” Chris nodded. “That makes sense. Instead of putting all your controls at the perimeter firewall, you're doing that crunchy center thing that John Kindervag talked about. It seems like we should be able to align our monitoring around those protect surfaces as they relate to those different lines of business.”

“How does the SOC know who or what needs access?” Harmony asked.

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

“The costs of logging everything might be too high to include our MSSP in step 4,” Noor said. “Storage costs are going down all the time, but you have to admit that there's a disincentive to send everything to our MSSP since you charge based on the volume of logs. You're not charging based on how effective your service is.”

“If we're not providing value, then we would expect you to leave and find another MSSP,” Chris admitted. “And I also understand that we weren't able to detect most of the activity that led up to your ransomware infection. We need to do better, not just for you, but for all our clients. I agree that we need to have some skin in the game. But we also need a feedback loop to help MarchFit improve your controls. The more false positives we can remove by stopping bad behavior, the more time we can spend investigating real suspicious activity.”

“There are also five design principles that we're following,” Harmony said, advancing to the next slide:

1. Define the protect surface.
2. Map the transaction flows.
3. Architect a Zero Trust environment.
4. Create Zero Trust policies.
5. Monitor and maintain each protect surface.

“I see that step five is to monitor and maintain each protect surface,” Chris said. “I think we can align our controls around your defined protect surfaces. This will help us provide better monitoring, but it will also allow us to provide better feedback on what is slipping through your controls. Or in Zero Trust terminology, we can help look for opportunities to remove trust from these different protect surfaces.”

Noor folded her arms, looking away from the screen for a moment. “How does the SOC keep up with all the changes that are going on in our environment?”

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

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

“How does that help?” Harmony asked.

“With our orchestration system, we've developed runbooks for these common attacks. For example, we have orchestrations for PowerShell, domain admin, or VPN compromises. And we also define what good behavior looks like. As we see bad behavior, we should be able to provide recommendations on additional controls, firewall rules, or config changes that could block those TTPs moving forward.”

“I'm still not sure if we're really doing Zero Trust here,” Dylan said. “Zero Trust is all about prevention. What we're talking about is reactive instead of being proactive.”

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

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

“I don't want to make it seem like there's a conflict of interest in giving you advice,” Chris said. “So you can feel free to buy additional tools or service from whoever you want to work with. But as your SOC, we want to help you find your blind spots.”

“What do you mean by blind spots?” Noor asked.

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

Chris nodded. “Another example could be network-based detection. While we definitely need server logs, that only gives us part of the picture. There are several good network detection and response, or NDR, tools out there, but you can also use the open source tool Zeek to provide network logs. We also know that ninety-eight percent of all network traffic is now encrypted, so decryption might be appropriate in some cases, or else we may need to find a solution that provides insight through analyzing headers. If you can enrich those network logs with proactive threat hunting, you not only remove a blind spot, but you improve your vision as well. Some of our clients have been able to detect whether some recent critical zero-day vulnerabilities were present in their networks or confirm for sure that they weren't impacted by a vulnerability because they had an NDR platform.”

“I think I'm starting to see why monitor and maintain is such an important part of the process,” Harmony said. “I wish we had been more focused on this stage from the beginning.”

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

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

“I completely understand your concern,” Chris said. “What some of our clients do is to have us monitor core services or provide access to your monitoring tools. We can also orchestrate a fallback in cases where we detect that a service has been disrupted. But we are in an age where we can't risk testing patches for months before moving to production. We've monitored this over time and patching has become less disruptive than it was ten years ago. Many of our clients have told us that it's less risky overall to patch first and then test afterward so that you've reduced your exposure.”

“So you're saying it's risky to be proactive, but it's more risky to be reactive?” Dylan asked.

Chris chuckled. “There are ways to be proactive without being risky. We have clients that have supplemented their controls with deception technologies like honeypots or honeytokens. I don't recommend making a honeypot device accessible to the public Internet. But if you do deploy those internally, they can be an early warning system to detect when an attacker has gotten past your defenses. For example, we know that as a part of the reconnaissance step in the ATT&CK framework, threat actors will enumerate all your public-facing server certificates and then target those servers. Putting a fake certificate there for an internal honeypot server can help you disrupt the initial access stage of attacks. The NSA has tested this, and they've shown that attackers spend less time in networks when deception tools are deployed.”

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

“I was thinking we should have weekly briefings instead of monthly,” Chris added. “But I agree we should provide better insights to align with your Zero Trust strategy.”

“OK, I think we're on the same page,” Noor said. “I've got to run to another meeting, but I'd like to have our Zero Trust team schedule another meeting to make sure you're in the loop on all of our progress so far.”

The wind was blowing heavily as Dylan walked one of the running paths that circled the building. He pressed the dial button for Aaron's number. It rang four times before Aaron answered.

“Calling already?” Aaron asked. “Everything OK?”

“Sorry for bugging you, but I wanted to ask about our SOC. We're aligning our Zero Trust processes with their monitoring. I wanted to make sure I wasn't missing anything.”

“It's critical that they can provide feedback to you on what controls are working and how you can improve. But have you asked yourself what happens after the SOC finds something?”

“What do you mean?” Dylan asked.

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

“What do you mean?”

“Sorry, gotta run,” Aaron interrupted, and hung up.

The Zero Trust team was waiting for Dylan in Harmony's basement command center. Someone had found a lamp so the room actually had some light this time. Isabelle was speaking with Rose as both examined Isabelle's tablet. There were more chairs now, but Brent and Nigel were standing together in the corner. Jefferson and Luis were on Zoom, but their images were now being projected onto a screen strapped with zip ties to the dropped ceiling, the ceiling tiles no longer sitting flush with the ceiling.

“We haven't talked yet about what happens after an incident,” Dylan began. “Up until now, other teams have been engaged with the incident response process and we've been focused on hardening other protect surfaces. The SOC and the incident response process is another protect surface.”

“In our SOC,” Luis began, “we've aligned our controls around the NIST Cybersecurity Framework since most of our clients are already using that to measure the maturity of their security programs.”

“Sorry. Wait, how many NIST standards are there?” Brent asked. “I thought there was just the one for Zero Trust?”

“Thousands,” Dylan said. “They make standards about almost everything. It helps support the economy by making businesses more efficient, and consequently more competitive.”

Luis shared his screen and displayed a picture showing the five steps of the NIST Cybersecurity Framework:

“The NIST Cybersecurity Framework is a five-step process to help organizations ensure that they've put adequate controls in place to organize their resources and protect themselves from cybercriminals,” Luis explained. “The framework is organized into a timeline around the assumption that the organization will be breached. The first two functions in the process, Identify and Protect, both happen before an incident happens. The final three functions, Detect, Respond, and Recover, all happen after an incident occurs. 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.”

“Since Zero Trust is all about prevention, doesn't it only apply to the first two steps?” Brent asked.

“It's true that Zero Trust focuses on prevention,” Dylan said. “And the model we use for helping us remove trust is by assuming we've already been breached. The whole reason that we send our logs to a centralized logging system is that we expect that the first thing a cybercriminal will do is try to remove any logs or other evidence of their activity. Zero Trust definitely continues after an incident occurs.”

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

“If a computer is compromised,” Dylan began, “we definitely won't trust it. But we've also got to decide whether we power it off or take it off the network. Do we monitor the compromised computer to see what other devices it may be connecting to?”

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

“All right,” Dylan said. “Let's start by reviewing our incident response plan. If the SOC is our protect surface, then the plan will be our map of transaction flows. Our CMDB and disaster recovery tools are the architecture. And the CISRT team will be the ones who need access. We'll begin a weekly SOC meeting to monitor the alignment of Project Zero Trust controls with how the SOC monitors the organization. What else are we missing?”

“We should do a practice fire drill before the product launch to make sure all of our processes are working correctly,” Isabelle said.

“You mean a tabletop exercise?” Dylan said.

“Exactly,” Isabelle said. “Can we hire a company to hack us as a part of the exercise? Make it a real test.”

“That does sound interesting,” Dylan said.

Another person walked behind Luis and handed him a paper. It was Jefferson.

“Jefe!” Harmony exclaimed. “You look like you actually got some sleep! Did you get promoted to the day shift?”

Jefferson bent down to join the conversation. “Hey, guys, yeah, day shift now! Sorry to interrupt. Our threat intel team just sent a note saying they've found an open Amazon S3 bucket with what looks like some of your data. Can you guys take a look?”

Key Takeaways

Alert fatigue is a real thing. A medium-sized company might produce millions of logs per day. A large organization might produce billions. Separating all the logs generated from normal activity from the tiny number of logs generated by a malicious actor is like finding a needle in a haystack. Many of the alerts that are generated are false positives, and this desensitizes the analyst performing the detective work. There are ways of mitigating this desensitization, but the most effective approach is to reduce or remove the noise that causes alert fatigue in the first place. Zero Trust can help with this, but only if the SOC is a part of your Zero Trust journey.

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.

For this reason, many organizations choose to outsource their SOC to a third-party Managed Security Service Provider (MSSP). An MSSP can provide real value in terms of maturing a cybersecurity program, but there are many challenges to overcome. MSSPs need to be able to support clients in many different industries using many different types of software. To be successful in this role, MSSPs need to be able to understand how your business works, what your crown jewels are, and what users are allowed to have access to. When a company is on its Zero Trust journey, the MSSP should be more than a participant—they should be a partner.

The final design principle of Zero Trust is to inspect and log all traffic. The final step in the Zero Trust design methodology is to monitor and maintain each protect surface. Implicit in both these directives is the notion that someone is analyzing the information being gathered from the environment and learning from it. There should be a feedback loop from the SOC to the organization on what potential vulnerabilities are being targeted and what changes can be made to better defend your protect surfaces. And based on their knowledge of how threat actors are targeting other similar organizations, they should be able to help you identify where your own blind spots are and where any potential deficiencies in tooling or configuration may be.

In other words, to be successful, an MSSP needs to have skin in the game. An MSSP needs to be able to help influence the organization to proactively update its defenses. The goal of an MSSP is to help enable an organization to reduce the dwell time of an attacker, which is another way of containing an attacker.

To help provide a measure of containment, a SOC should report using a framework that shows how an organization is disrupting attackers' operations. The MITRE ATT&CK framework is the leading knowledge base of attacker tactics, techniques, and processes. This framework can provide needed context to organizations to understand what an attacker is doing and what they might do next. This context is critical in helping contain and reduce dwell time of attackers.

The primary way that a SOC will interact with an organization is through its incident response (IR) process. Many MSSPs offer a variety of services, and an IR response can be as little as sending a company an email when the SOC has observed some suspicious behavior to completely managing the quarantine and patching of an infected device. The more that the SOC can be engaged to support a client, the better the analysis that Zero Trust principles require. To reinforce the client's Zero Trust journey, the SOC should align its monitoring around the client's Zero Trust protect surfaces to better apply that analysis toward improving controls.

The NIST Cybersecurity Framework defines five core functions that all organizations need to be able to accomplish to have a complete cybersecurity program: identify, protect, detect, respond, and recover. These functions align with a timeline around a data breach, so that after the protect stage, you need to plan for what you will do after some malicious activity happens. You should be able to detect when something bad happens, then respond to it, and then recover your business to the place it was before an incident. The SOC will help you perform all three of those final functions.

Almost every cybersecurity program in the United States will be expected to align with the NIST Cybersecurity Framework. The NIST Computer Security Incident Handling Guide (Special Publication 800-61) is the specific standard for how incident response plans should be written. Incident response plans should be tested and updated regularly against real-world scenarios to ensure that they meet the needs of the business.