How Netskope Uses Cloud Exchange to Turn Signals into Action

Author:  Stevan Pierce & Madhura Sridhar

Date: March 16, 2026

Modern security teams are drowning in “partial truths.”

Your email gateway flags suspicious links. Your EDR finds a questionable process. Your SASE platform sees risky SaaS behavior. Your IAM solution logs a strange login pattern. Each tool is doing its job yet each is also speaking its own language, in its own console, with its own definition of “risk.”

The result is a familiar and frustrating reality:

• Analysts jump between dashboards
• Teams argue over whose alert is “right”
• Critical context is trapped in silos
• And incident response lags behind the adversary

At Netskope, we faced this exact problem in our own environment. As “Customer Zero,” our security team not only secures Netskope but also pushes our own platform to its limits, trying to solve the same challenges our customers wrestle with every day.

This is where Netskope Cloud Exchange (CE) comes in.

Cloud Exchange is how we connect the Netskope One platform with the tools we already rely on: email, endpoint, cloud, identity, and ticketing.  So that isolated security signals become coordinated, automated action.

In this article, we’ll walk through how our Customer Zero team uses Cloud Exchange’s three of the four core pillars.  

• Cloud Threat Exchange (CTE) – centralized, automated threat intelligence
• Cloud Risk Exchange (CRE) – dynamic, cross-stack user risk scoring
• Cloud Ticket Orchestrator (CTO) – closing the loop from detection to remediation

…and how together, they help us break down tool silos, move at the speed of the adversary, and build a modern, data-driven security operating model.

From Siloed Tools to a Connected Security Fabric

Security programs rarely fail because they lack tools. They fail because those tools don’t work together.

Our starting point was simple:

Use all Netskope features, operationalize them end-to-end, and lead by example!

In practice, that meant tackling several core problems:

• Too many consoles: Email, endpoint, cloud, identity, ticketing, SIEM, SOAR, each a separate universe.
• Inconsistent context: A “high risk” user in one system might be “medium risk” in another.
• Manual glue-work: Analysts copying IOCs from one tool to another, or manually opening tickets for every meaningful policy violation.
• Slow remediation: Threat indicators identified in one system could take hours or days to show up in enforcement points elsewhere.

Cloud Exchange is our answer to this: an open integration platform that enables data sharing between Netskope and the rest of the security ecosystem, SIEM, SOAR, threat intel, ticketing, EDR, email security, and more.

Instead of every product talking only to its own backend, Cloud Exchange becomes the connective fabric that:

• Normalizes data
• Automates sharing
• Drives risk-aware decisions
• Kicks off repeatable workflows

The rest of this article breaks down how each CE module contributes to that fabric.

Cloud Threat Exchange (CTE): A Unified Threat Intelligence Pipeline

Threat intelligence is only as valuable as your ability to use it everywhere that matters.

Most security teams subscribe to multiple feeds, receive partner intel, and generate internal IOCs from email, endpoint, cloud, and infrastructure. But without a unifying layer, intel often gets stuck:

• In the SIEM, where it’s great for hunting but not for enforcement
• Inside an email gateway, not visible to cloud controls
• Locked in an EDR console, not shared with SASE or web security

Universal Ingestion: Bring All the Feeds to One Place

With Cloud Threat Exchange (CTE), we centralize threat ingestion so that our security pipeline starts from a single, authoritative source of truth.

In our Customer Zero environment, CTE:

• Automatically ingests curated threat feeds
• Supports STIX-formatted IOCs, so we can handle structured intel from multiple vendors
• Integrates with Feedly’s AI-powered intelligence engine, turning massive volumes of data into curated, prioritized indicators
• Pulls from any TAXII-compliant source, giving us flexibility to plug in third-party or industry-specific feeds
• Ingests supply chain risk signals from GitHub, such as repos or artifacts that might introduce code-level risk

Structured Threat Information Expression (STIX): Structured Threat Information Expression (STIX) is a language and serialization format used to exchange cyber threat intelligence (CTI). 

Trusted Automated Exchange of Intelligence Information (TAXII) is an application protocol for exchanging CTI over HTTPS.

All of these feeds are organized into specific CTE Lists (for example, a CrowdStrike_CTE_List), giving us clear, manageable groupings that can be referenced downstream.

Bidirectional Sharing: No More One-Way Streets

In many environments, threat intel flows in one direction. You import feeds, but you don’t necessarily share back out your own detections in a structured way.

We wanted something better: bidirectional sharing that turns every detection point into both a sensor and a publisher.

With CTE, we:

• Share email-borne threat indicators from Mimecast malicious URLs, sender reputation data, attachment hashes into the central intel pipeline
• Ingest endpoint-detected IOCs from CrowdStrike Falcon, so indicators seen at the endpoint become enforceable in the cloud
• Propagate AWS GuardDuty findings things like anomalous network behavior, known-bad IPs, or compromised resources into the same intel fabric
• Combine all of this into a unified threat intelligence pipeline that feeds Netskope and other connected tools

The effect is powerful: a phishing campaign spotted by Mimecast doesn’t just live in email anymore. It can result in real-time web blocks, CASB policy triggers, or ZTNA enforcement through Netskope One because those indicators are centrally known and continuously updated.

From Intel to Enforcement: Architecture That Actually Does Something

CTE isn’t just a repository; it’s an engine that connects sources to enforcement:

1. Centralized Collection
   • Feedly
   • Mimecast
   • GuardDuty
   • TAXII feeds
   • GitHub supply chain signals
2. CTE List Organization
   • Indicators are normalized and stored in dedicated lists, such as Feedly_IOCs, Mimecast_Email_IOCs, CrowdStrike_CTE_List, and more.
3. Policy Integration with Netskope
   • These lists are then fed directly into Netskope Real-Time Policies.
   • When a user clicks a URL, accesses a domain, or attempts a connection, it can be compared against our CTE-driven lists in real time.

The end result is simple: as new IOCs arrive or old ones are updated, our enforcement points adapt automatically without analysts manually copy-pasting anything.

Cloud Risk Exchange (CRE): Dynamic Risk Scoring Across the Stack

While IOCs capture what is bad, user and entity risk scores help us answer who deserves more scrutiny right now.

Most organizations collect risk signals from multiple places:

• Endpoint (EDR)
• SASE / cloud security
• Email
• Identity access patterns
• Other telemetry sources

But there are two big problems:

1. Risk is calculated differently by each tool.
2. Risk often lives and dies within a single product.

Cloud Risk Exchange (CRE) is how we fix that.

User Confidence Index (UCI): A Living Risk Score

At the heart of CRE is Netskope’s User Confidence Index (UCI), a dynamic risk score that reflects a user’s current behavior and posture across different systems.

What we do internally:

• Feed Mimecast email threat signals into UCI
  • Repeated interaction with malicious emails? UCI goes down.
  • Clean behavior over time? UCI recovers.
• Combine that with SaaS, web, and endpoint behaviors from Netskope and other partners
  • Risky app usage
  • Data exfiltration patterns
  • Anomalous access to sensitive resources

This turns UCI into a living representation of risk, not just a static label.

Aggregating Risk Scores: From Fragmented Grades to a Single View

Many security vendors produce their own proprietary scores:

• EDR providers might have internal risk or threat scores
• SASE platforms may tag high-risk locations, apps, or sessions
• Email security tools like Mimecast use systems such as a “SAFE Score Grade” (A/B/C/D/F)

CRE is where we normalize and aggregate these into a single, actionable score:

• Combine risk signals from EDR providers
• Incorporate SASE risk data
• Bring in other telemetry sources to fill in gaps
• Calculate a real-time Aggregated Risk Score that we can consistently interpret and act upon

Instead of an analyst trying to reconcile whether “Mimecast says C, EDR says High, Netskope says Medium,” we get one unified answer: This user’s risk is 237, and that’s below our trusted threshold.

Automated Remediation: Let the Risk Drive the Controls

Risk scoring is only useful if it changes something in the environment.

In our Customer Zero environment, CRE drives automated remediation:

• Continuous monitoring of the aggregated risk score for each user
• Threshold checks, e.g., Is the score < 251?
• If risk is high:
  • Automatically remove users from secure groups or privileged roles
  • Tighten access policies
  • Add friction where appropriate (MFA challenges, device posture checks, etc.)
• If risk improves:
  • Automatically add users back into secure groups
  • Relax controls to restore their normal experience

This is how we align day-to-day access with real, observed behavior without requiring an analyst to manually reassign groups or rewrite policies for every incident.

Cloud Ticket Orchestrator (CTO): Closing the Loop with Workflow

Even with great intel and robust risk scoring, incidents still need human judgment and structured processes.

That’s where Cloud Ticket Orchestrator (CTO) comes in.

From Detection to ITSM: No More “Forgotten Alerts”

In many organizations, a policy violation or high-risk detection generates an alert but not necessarily a tracked task. Analysts might work from email notifications, custom dashboards, or ad-hoc spreadsheets.

CTO helps us formalize detection into real, trackable work:

• Policy violations trigger alerts in Netskope
• These alerts are sent into Cloud Exchange
• CTO automatically creates tickets in ITSM queues such as ServiceNow or Jira

This gives us:

• A consistent record of what was detected
• Ownership and SLA tracking via established ITSM workflows
• Better reporting on the types and volumes of incidents we see

Triage, Feedback, and Continuous Improvement

Once a ticket exists, the human side of security takes over:

• Analysts triage and escalate alerts as needed
• They identify and document false positives
• Those decisions can be fed back into Netskope and CE configurations
  • Refining detection rules
  • Tuning thresholds
  • Adjusting automated responses

In other words, CTO doesn’t just throw tickets over the wall, it helps build a closed feedback loop:

1. A detection triggers a ticket.
2. Humans investigate, enrich, and label the event.
3. Their outcomes inform better future automation.

Over time, this shrinks the manual workload on the “easy” cases and frees human expertise for the truly ambiguous or strategic ones.

Putting It All Together: A Modern Product Operating Model for Security

The final slide in our presentation hints at a broader shift:

“Killing Silos: Bringing the Product Operating Model to IT and Security.”

What we’ve described isn’t just a string of integrations. It’s a move toward treating security as a product, not a collection of projects:

• Clear inputs and outputs – telemetry in, policy/action out
• Tight feedback loops – detections -> tickets -> learnings -> better detections
• Continuous improvement – automation gets smarter as more data flows through it
• Customer-centric mindset – in our case, the “customers” are both Netskope’s workforce and the broader Netskope customer community watching what we do as Customer Zero

By using Cloud Exchange to break down tool silos, we’ve seen several tangible benefits:

• We move closer to the speed of the adversary by automating threat intel propagation and risk-based responses.
• We reduce friction between tools and teams, because they now share context and a common understanding of risk.
• We gain unified visibility across endpoint, email, and cloud, rather than juggling disconnected snapshots.
• We convert “alerts” into “actions” via CTO and our ITSM integrations.

Key Takeaways

If you’re considering a similar journey in your own environment, here are the core lessons from our Customer Zero experience with Cloud Exchange:

• Centralize your threat intelligence. Let tools like CTE aggregate feeds from sources such as Feedly, TAXII, Mimecast, CrowdStrike, GuardDuty, and GitHub and push them directly into enforcement points.
• Unify your risk picture. Use CRE to bring together scores from EDR, SASE, email, and other telemetry into a single, real-time Aggregated Risk Score that actually drives policy.
• Automate with guardrails. Map risk scores and threat indicators to clear, automated actions: removing users from secure groups when risk spikes, restoring access when it falls.
• Turn detections into work, not noise. Use CTO to create ITSM tickets automatically, drive consistent triage, and feed analyst decisions back into your detection and response logic.
• Think in products, not point solutions. Design your integrations and workflows as if you were building a product for your internal stakeholders: predictable, observable, and continuously improved.