Rose's cheek was pressed into the mat. Her opponent, Mark, was sitting on her back, elbow pressing against her head and holding her down. Everything in her screamed to tap out. Instead, she rolled to her side while she pulled her legs up to her chest into a fetal position, breaking the hold. At the same time, she slammed her elbow into Mark's ribs. She followed this by grabbing his wrist and twisted until she wrapped her legs around his arm. He groaned as she followed with several rabbit punches into the same rib that she'd found with her elbow until she realized he was slapping the mat with his free hand. Reluctantly, she let go of him.

She stood up and retied the belt of her gi that had come undone as she had been pinned. She bumped fists with Mark. There weren't many women at the gym and usually the men didn't want to fight for fear of hurting her, or worse, getting beaten by her. Maybe she'd have to let him win next time to keep from running out of sparring partners. She wondered about that as she walked back to grab her water and check her phone. She saw she had missed several calls and texts, but didn't recognize the numbers. She had to brush her hair out of her face before she could get the facial recognition to work.

She dropped the phone when she read the last message. “This is 3nc0r3. I know who you are and I will pay $5 million for information about Zero Trust at MarchFit.”

Back at the office, Dylan checked the meeting invite on his phone for the third time. It said “Conference Room 217.” He double-checked the room number, but the door was closed so he didn't want to interrupt another meeting. He could hear people talking in the room, so he hesitated for a moment before going in.

Dylan couldn't see through the glass wall of the conference room. It was completely covered by hundreds of Post-it notes. He heard Isabelle's voice and decided it was OK to go in. As he entered the room, he realized that it wasn't just one wall, but all of the walls were covered in Post-it notes. The notes went from one color to another as they wrapped around the room. Isabelle was at the far end of the room writing a note with a Sharpie. There were two other people in the room; both looked up as Dylan entered.

“Is this a prank or something?” Dylan chuckled. He realized the whole surface of the conference room table was also completely covered.

“Oh, good—you're here,” Isabelle said, looking at her watch. “You know Kofi already, and this is Dave,” she said, pointing to the two other attendees. They stood up to shake Dylan's hand.

“I've been thinking about the cloud,” Isabelle said.

“This whole open S3 bucket thing has been bothering me, too,” Dylan admitted. “We've confirmed that there wasn't any sensitive information in it, but I'm not sure how we keep up with every new issue out there before they come back to bite us. It seems like there are a handful of common mistakes we're making with our cloud services. The cloud is just too big a protect surface for me to wrap my mind around.”

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

“Did Harmony get you the list of cloud apps?” Dylan asked.

“Yes. She ran a report from our firewall that showed all traffic going to the most common cloud applications,” Isabelle confirmed. “It included some of the apps we expected, like Office365. But there was also a lot of traffic going to unsanctioned cloud applications.”

“Like what?” Dylan asked.

“We officially support OneDrive as our online file storage. But we still see traffic going to Dropbox, for example. It's hard to tell at this point whether they're being used for a specific business reason or for personal things,” Isabelle said.

“Shouldn't we just block the ones we don't know about?” Kofi asked.

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

“That's why Dave is here,” Isabelle said. “He's our head of purchasing.”

“I reviewed our purchases for the last year, and all of the Post-its with stars on them are ones we found that were paid by a purchasing card,” Dave said. There were a lot of stars up on the wall. “We know there are probably some that are free or trial versions.”

“We also can't see what all the people working from home are using,” Dylan said. “That could be a blind spot for us.”

“That bothers me,” Kofi said. “All of those services have terms and conditions that people are clicking through. This list will be very helpful when we review our contracts to make sure we're not opening ourselves to risks.”

“Well, let's start with the ones we have. It looks like you guys have already gotten us off to a great start. Let's focus on the applications that may have sensitive info,” Dylan said.

“We should definitely focus on those as their own protect surfaces. But I was actually wondering if the protect surface we should be focusing on is actually our project management process,” Isabelle said.

“What makes you say that?” Dylan asked.

“There are a lot of things that we need to do every time we bring in a new vendor. The cloud is just another way of saying we're outsourcing a service to another company. But if we don't have a process to make sure our vendors are secure before we onboard them, then we're setting ourselves up to fail,” Isabelle said.

Dylan looked around at all the Post-it notes. He realized that the different colors of Post-it notes actually represented the different categories of vendors. Yellow roughly corresponded to the services running on Amazon. Blue notes were Microsoft Azure. Pink were various SaaS services. “So if the protect surface is project management, then mapping the transaction flows is really about understanding the contract process?” he wondered aloud.

“Exactly,” Isabelle said. “We've done a lot of work getting different departments to work with us earlier so that we're not surprised when a new request comes in. And it's helped us reduce the amount of shadow IT. But we need help from legal, which is why I invited Kofi to join us.”

“We follow three different processes for contracts,” Kofi began. “Most contracts go through our purchase order process. We include some standard terms in every PO, including some basic security language. Some other organizations will want us to sign their contract, and we will negotiate our standard terms and conditions into each contract. This can take some time depending on how complex the negotiation is and how much the vendor charges.”

“You said there were three options?” Dylan asked.

“In some cases, a vendor will agree to use our standard contract. That's the easiest,” Kofi said.

“What do our standard contract terms say?” Dylan asked.

“We ask every vendor to commit to having insurance, encrypting sensitive data, paying the costs of a data breach, and that they have security monitoring in place and perform annual audits,” Kofi said.” If something happens, we ask them to pay the costs of breach notifications. And if there is a data breach, we indicate that this is a breach of contract and we can get out of the agreement if we need to.”

“That all sounds good,” Dylan admitted. “Do we just take vendors at their word? Or do we validate that they have security controls in place?”

“At my last company we had a staff of fifteen individuals who would go out and audit our most important vendors,” Kofi said. “But I know this isn't feasible for us. I've heard that there are several security vendors that track companies' cybersecurity ratings similar to how the credit ratings agencies track your credit score. I've been thinking that we should use one of those services to monitor our vendors instead of having our own internal team that audits. We can also supplement this with an industry security questionnaire like the one for Shared Assessments Standard Information Gathering, or SIG, and compare their answers with their vendor scorecard.”

“That's a great start, Kofi,” Dylan said. “I know the Cloud Security Alliance has their Security Trust Assurance and Trust registry as well. We can search through that to see each vendor's Consensus Assessments Initiative Questionnaire, or CIAQ, as well. That could help us see if any of the vendors on the list have any issues. But I'm also worried about how much visibility we're losing when we're outsourcing to the cloud. Most of the data that our SOC collects is from servers or network traffic. Most of our applications are SaaS based, and that means we're not getting much data from those other vendors.”

“What about a CASB?” Dave asked. Everyone turned to stare at him.

“What's a CASB?” Isabelle asked.

“It's a cloud access security broker,” Dave said. “I did an RFP for a CASB project at my last company. For some of our applications, it acted as a cloud-based proxy. Since all of our traffic was flowing through that, we could collect logs from it. And we customized it for some critical applications to be able to do more specific activity monitoring.”

“That was just for some applications?” Dylan asked.

“The CASB also had APIs developed for some of the more popular applications out there like SharePoint or OneDrive,” Dave said. “Those were easy to turn on since there was no proxy to configure. And those had a lot more detail already built in for activity monitoring. It was also a great way to detect sensitive information being stored in the cloud.”

“Wait,” Isabelle said, going back to her tablet. “CASB sounds familiar. We had a project request for this last year. The scope of the project was just for one file- sharing application. But the project was abandoned after the company switched to another tool. But I bet we're still licensed for it.”

“Can you ask Noor for help prioritizing the list?” Dylan asked. “Let's focus on the highest-risk SaaS services to secure first. I would think that online file storage should be one of the first since there's probably some sensitive data shared on those apps for teams to work on. Same with SharePoint, Jira, Zoom, or Slack.”

“It's getting late, but I'll follow up with her tomorrow,” Isabelle said.

“Let's get back to your original point, Isabelle,” Dylan said. “I think the project process is a great way to enforce some security standards across the board. We can include phase-gates in the process where we separate a project into phases that are separated by a decision point. The CIO or a governance group could then decide to proceed with subsequent phases or not.”

“What kinds of protections should we be looking for?” Dave asked.

“Obviously we want to check for any unsecured cloud storage containers, like the open Amazon S3 bucket we found. Our SOC is now regularly checking for this, but it would be better if we secured them before a project went live.”

“That makes sense,” Dave said. “What else?”

“First, we should start with making sure those applications are automatically set to be patched,” Dylan said. “We need to require MFA for all applications. And we should know whether they support full MFA or just SMS. We should deploy a WAF to all our cloud apps if we can. Make sure insecure ports like telnet are disabled. And the SOC should be aware of applications coming online so they can monitor for any remote access attempts.”

“What about error pages?” Isabelle asked.

“Error pages?” Dylan asked.

“I've heard error pages can sometimes leak information,” Isabelle said. “I heard from one project manager that their AWS install keys were being leaked by an error message in one of their pages. That allowed an attacker to create their own crypto mining servers using that key. At the end of the month they got a huge bill for those services.”

Dylan looked at the Post-it notes across the glass wall. He could see people walking down the hallway passing behind the blue Microsoft Azure columns of Post-it notes, then passing behind the orange Amazon Post-its, then on to the pink SaaS notes. They stopped, turned, and went back as though they had forgotten something, passing behind all those Post-its again.

“There's a lot of interaction among all these services, isn't there?” Dylan wondered. Isabelle, Dave, and Kofi all looked at the board where he was looking. “We're talking about visibility and control for users as they interact with these apps. But I think we're still missing something—the people.”

Twenty minutes after the meeting had ended, Dylan was alone in the conference room, still looking at the Post-its. He pressed the button on his cell to call Aaron and explained what they were doing. They needed to be able to enforce policy across all their apps and all their various cloud providers. And they needed to be able to manage policies across all of those different apps. Aaron listened politely for a few minutes, then interrupted. “Software-defined perimeter.”

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

“That's how we're supposed to manage all our cloud services sprawl?” Dylan asked. “With SDP?”

“It's still the wild west out there,” Aaron admitted. “There are a lot of ways to do SDP. But the best approach I've seen uses another acronym, SASE or SSE. Secure Access Services Edge or just Secure Services Edge can control policy for access to all applications and integrate with your identity system to provision access to all your users with the limited permissions they need. Those agents can also enforce isolation of devices to prevent lateral movement inside your network. And some have remote browser isolation capabilities so that if one of your users visits a malicious website, the malware is detonated in a sandbox in the cloud, not the user's computer.”

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

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

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

“You've made a lot more progress than you think,” Aaron said. “Don't forget how far you've come already. But unfortunately, no, that's not all. Zero Trust is about the journey. You'll definitely come up with more trusts you need to remove.”

Dylan walked out of the conference room and turned left down the hallway. He turned and pressed the button for the elevator. Dylan was too tired to even hold the phone up to his ear or put it back in his pocket, so he just held it to his side waiting for the elevator.

Boris stepped up beside Dylan, and they both waited for the elevator in silence. Boris was holding his phone reading an email but stopped to look at Dylan. The door to the elevator dinged. Boris got in first, and Dylan walked behind while Boris pressed for the lobby.

“We need to have standards,” Dylan said as the doors closed. It was completely silent for several seconds as they stood there.

“You okay, Dylan?” Boris asked.

“I've been thinking about standards,” Dylan said.

The doors opened to the lobby. It was dark outside the building. “High standards or low standards?” Boris asked.

“Sky high,” Dylan confirmed. “Like cloud standards.”

“Oh, you're talking about work,” Boris chuckled. “I was worried this was about to get personal or something.”

“We talked the other day about Kubernetes.”

“Yeah. Security as code. We've already worked in some security testing into our process. We're agile, so we move fast!”

“Did you know that I was hired to be the director of cloud infrastructure?” Dylan asked.

“I hadn't heard. I thought we were going to hire for 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?”

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

A few hours later, Dylan set his empty pint glass down on the paper napkin. The bar had turned out to be a hole in the wall that he had driven past every day to get to the office. The floors sagged when you walked around. They were missing several balls from the pool table, and there was only one good cue. But he was starting to feel at home. More than that, somehow, he was part of a team.

When he thought about it, things had changed since starting at MarchFit. He didn't run by himself anymore. There was a group that met every morning before work. And he was actually having a drink with some developers, which was weird.

Olivia walked up onto the karaoke stage. She had been drinking in a corner booth and he hadn't noticed she was there.

“LA had been too much for the man,” she sang as the opening notes to Glady's Knight's “Midnight Train to Georgia” began playing. Dylan found himself singing along to the backup singers, line along with the rest of the bar.

He thought he had seen everything, but then Rose sat down next to him and waved to the bartender. The bartender set down two shot glasses in front of them and began to pour.

“I'm not sure who to talk to about this,” Rose said, pushing his shot glass toward him, then grabbing her own and downing it in one fluid motion.

“Is everything okay?” Dylan asked. He considered for a second, then downed his shot.

“I heard from 3nc0r3 again,” Rose admitted.

“Did he post something? I haven't seen any more Twitter notifications,” Dylan said, getting out his phone. In all the excitement he hadn't checked his phone a single time.

“No, he contacted me directly,” Rose said.

Dylan looked up at her to see if she was serious. “What?” Dylan asked, confused.

“He offered me money to give him information about MarchFit,” she said, but as she spoke, she began talking faster. “I didn't tell him anything; I don't understand how he even knows who I am. And he knew things. He knew I was working on Project Zero Trust.”

“It's okay. We can check with our SOC to see if they've seen any suspicious activity on your account. We should go on lockdown.” He began dialing his phone.

“Sorry, boss, but I don't think that's the play here,” Rose said.

“What do you mean?” Dylan asked.

“He's desperate,” Rose said. “He wouldn't have targeted me unless he couldn't get in by himself. That means Project Zero Trust is working. He thinks I'm the weak link.”

“You shouldn't think that,” Dylan started to say.

“Oh, I'm definitely not the weak link,” Rose interrupted. “If we ignore him or block him now, he's just going to come back again from some other angle like he's been doing for months. This is our chance to stop him. We're going to reach out to Agent Smecker. ”

“You want to set up a sting? Rose, that's amazing. Most people would have probably just kept quiet and taken the money,” Dylan said.

“Oh no. I couldn't have spent it. And if I did, I would have gotten caught for tax evasion. And 3nc0r3 would have set me up so I would be looking over my shoulder for years,” Rose said. “This is way better.”

“Why do you say that?” Dylan asked.

“I'm going to be the one that takes down 3nc0r3,” Rose said with a wicked smile. “I'm going to be a legend.”

Key Takeaways

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.

Because of this, the “cloud” isn't one protect surface; it's many different protect surfaces.

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.

Shadow IT refers to technology systems that aren't managed by the IT department. Because shadow IT services don't follow company policy, this can create potential liabilities for the organization, like not meeting security standards or going through the appropriate contract approval process. Shadow IT isn't limited to cloud services, although the ease with which individuals can create cloud services means they are much more challenging to manage. To provide a more complete picture, regular discovery reports should be run for new services.

One of the challenges with Zero Trust in the cloud is that many applications don't provide the same level of visibility that organizations would have been able to gain if the service were running on premises. Although some cloud applications can be configured to send logs to your SIEM, many applications won't. Some cloud applications may have an API to send this data, but not all. You need insight not just into the application but into specific user activity within the application itself.

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

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.

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 organizations use encryption to secure their apps, attackers can discover flaws in APIs using man-in-the-middle attacks to reverse-engineer paths and exfiltrate data.

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 APIs are so dynamic, organizations also need API monitoring tools that can discover APIs in real time and integrate with existing API gateways.

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 how Experian and Equifax provide credit ratings for individuals. For all significant technology contracts, IT, security, and legal should review the terms of the agreement and approve them before it is signed. These teams must be able to say “no” to a vendor if their security has significant red flags. And you should be able to get out of a contract if the vendor experiences a breach.