Building a Zero-Trust Network with OneDot SASE
The traditional security model of "trust but verify" is fundamentally broken in today's cloud-first, remote-work environment. Organizations need a new approach: Zero Trust, which operates on the principle of "never trust, always verify." This comprehensive guide will walk you through implementing a zero-trust security architecture using OneDot SASE (Secure Access Service Edge).
Understanding Zero Trust
Before diving into implementation, let's clarify what zero trust actually means.
Core Principles
Zero trust is built on three fundamental principles:
- Assume Breach – Act as if attackers are already inside your network
- Verify Explicitly – Always authenticate and authorize based on all available data points
- Least Privilege Access – Limit user access with just-in-time and just-enough-access (JIT/JEA)
Why Traditional Perimeter Security Fails
The traditional "castle and moat" model fails because:
- No perimeter exists – Users access applications from anywhere
- Cloud apps are outside the corporate network
- Insider threats are as dangerous as external attacks
- Lateral movement allows attackers to spread after initial compromise
What is SASE?
SASE (Secure Access Service Edge) combines network and security functions in a cloud-delivered service. It includes:
Network Functions:
- SD-WAN
- WAN optimization
- CDN
Security Functions:
- Secure Web Gateway (SWG)
- Cloud Access Security Broker (CASB)
- Zero Trust Network Access (ZTNA)
- Firewall-as-a-Service (FWaaS)
OneDot SASE delivers all these capabilities in a unified platform.
Planning Your Zero-Trust Implementation
Step 1: Inventory Your Assets
Create a comprehensive inventory of:
# Example asset inventory structure
assets:
applications:
- name: "CRM System"
type: "SaaS"
sensitivity: "high"
users: ["sales", "marketing", "support"]
- name: "Internal Wiki"
type: "self-hosted"
sensitivity: "medium"
users: ["all_employees"]
data:
- category: "customer_data"
classification: "confidential"
location: ["aws_s3", "salesforce"]
- category: "financial_records"
classification: "restricted"
location: ["on_prem_db", "oracle_cloud"]
users:
- group: "engineering"
count: 150
locations: ["office", "remote"]
devices: ["laptop", "mobile"]
- group: "contractors"
count: 45
locations: ["remote"]
devices: ["laptop"]
Step 2: Define Access Policies
Determine who should access what under which conditions:
Risk-Based Access Control:
- User identity
- Device posture
- Location
- Time of day
- Behavior patterns
Example Policy Framework:
{
"policy": "high_sensitivity_data_access",
"conditions": {
"required": [
"verified_identity",
"managed_device",
"compliant_os_version",
"healthy_security_posture"
],
"location": {
"allowed_countries": ["US", "UK", "CN"],
"blocked_networks": ["public_wifi"]
},
"time": {
"allowed_hours": "business_hours",
"timezone": "user_local"
}
},
"access_level": "read_write",
"mfa_required": true,
"session_duration": 3600,
"logging": "detailed"
}
Step 3: Segment Your Network
Microsegmentation limits lateral movement:
Traditional Segmentation:
┌─────────────────────────────────────┐
│ Entire Corporate Network │
│ (All resources accessible to all │
│ users once inside the network) │
└─────────────────────────────────────┘
Microsegmentation:
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Segment A │ │ Segment B │ │ Segment C │
│ (Finance) │ │ (HR) │ │ (Eng) │
└───────────┘ └───────────┘ └───────────┘
↓ ↓ ↓
Isolated Isolated Isolated
Access Access Access
Implementing OneDot SASE
Phase 1: Deploy SASE Connectors
Start by deploying OneDot SASE connectors in your environment.
For Cloud Applications
# Install OneDot SASE connector for AWS
curl -O https://downloads.onedotnet.com/sase/aws-connector.sh
chmod +x aws-connector.sh
./aws-connector.sh --region us-east-1 --vpc-id vpc-12345678
# Verify connector status
onedot-sase connector status
For On-Premises Applications
# Docker deployment for on-prem connector
docker run -d \
--name onedot-sase-connector \
--restart always \
-v /var/run/docker.sock:/var/run/docker.sock \
-e SASE_TOKEN="your_token_here" \
-e CONNECTOR_NAME="datacenter-1" \
onedotnet/sase-connector:latest
# Kubernetes deployment
kubectl apply -f https://downloads.onedotnet.com/sase/k8s-connector.yaml
Phase 2: Configure Identity Provider Integration
OneDot SASE integrates with your existing identity provider.
SAML Integration Example
<!-- Configure SAML SSO with OneDot SASE -->
<EntityDescriptor entityID="https://sase.onedotnet.com">
<SPSSODescriptor>
<NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress
</NameIDFormat>
<AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://sase.onedotnet.com/auth/saml/callback"
index="1" />
</SPSSODescriptor>
</EntityDescriptor>
OIDC Integration
// Configure OIDC with Okta
const config = {
issuer: 'https://your-org.okta.com',
clientId: 'your_client_id',
redirectUri: 'https://sase.onedotnet.com/auth/callback',
scopes: ['openid', 'profile', 'email', 'groups'],
pkce: true
};
Phase 3: Set Up Device Posture Checks
Ensure only compliant devices can access resources.
Device Posture Requirements:
# Example device posture policy
device_policy = {
"os_requirements": {
"windows": {
"min_version": "10.0.19041", # Windows 10 20H1
"required_updates": "all_critical"
},
"macos": {
"min_version": "12.0", # macOS Monterey
"required_updates": "all_security"
},
"ios": {
"min_version": "15.0",
"jailbreak_allowed": False
}
},
"security_software": {
"antivirus": {
"required": True,
"definitions_age_max_days": 7
},
"disk_encryption": {
"required": True
},
"firewall": {
"required": True,
"state": "enabled"
}
},
"device_management": {
"mdm_required": True,
"enrollment_status": "verified"
}
}
Phase 4: Create Access Policies
Define granular policies in the OneDot SASE console.
Example: Engineering Team Access to Production
policy_name: "Engineering Production Access"
description: "Allow engineering team to access production environment"
conditions:
identity:
groups: ["engineering", "devops"]
mfa: required
device:
managed: true
os_patch_level: current
antivirus: active
location:
allowed_countries: ["US", "CN", "UK"]
deny_vpn_exit_nodes: true
time:
allowed: "business_hours"
timezone: "UTC"
risk_score:
max_acceptable: 60
actions:
allow:
- ssh_access
- kubectl_access
- database_read
deny:
- database_write
- config_changes
log: all_requests
session:
max_duration: 14400 # 4 hours
idle_timeout: 1800 # 30 minutes
recording: enabled
Phase 5: Enable Application-Level Security
Apply security controls at the application layer.
Secure Web Gateway (SWG)
// Configure URL filtering and threat protection
const swgPolicy = {
categories: {
block: [
'malware',
'phishing',
'adult_content',
'gambling',
'illegal_activities'
],
warn: [
'personal_email',
'social_media',
'file_sharing'
],
allow: [
'business_tools',
'research',
'approved_saas'
]
},
ssl_inspection: {
enabled: true,
exempt_categories: ['healthcare', 'financial'],
exempt_domains: ['*.bank.com', 'healthcare-provider.com']
},
data_loss_prevention: {
scan_uploads: true,
scan_downloads: true,
block_sensitive_data: ['ssn', 'credit_card', 'api_keys']
}
};
Cloud Access Security Broker (CASB)
# Monitor and control cloud app usage
casb_policies:
- name: "Restrict Shadow IT"
action: block
conditions:
app_category: "unsanctioned"
risk_level: "high"
- name: "Monitor File Sharing"
action: alert
conditions:
activity: "external_share"
data_classification: "confidential"
- name: "Enforce DLP in SaaS"
action: block_and_alert
conditions:
data_patterns:
- "credit_card"
- "ssn"
- "api_credentials"
destination: "external"
Monitoring and Maintenance
Real-Time Visibility
OneDot SASE provides comprehensive visibility into:
Access Logs:
-- Query access logs
SELECT
timestamp,
user_id,
device_id,
source_ip,
destination_app,
action,
risk_score,
policy_applied
FROM access_logs
WHERE timestamp > NOW() - INTERVAL '24 hours'
AND action = 'blocked'
ORDER BY risk_score DESC;
Security Analytics:
- Anomalous access patterns
- Impossible travel scenarios
- Brute force attempts
- Data exfiltration indicators
Automated Response
Configure automated responses to security events:
# Example automated response configuration
incident_response = {
"brute_force_detected": {
"actions": [
"lock_user_account",
"require_password_reset",
"notify_security_team",
"trigger_investigation"
],
"threshold": {
"failed_attempts": 5,
"time_window": 300 # 5 minutes
}
},
"impossible_travel": {
"actions": [
"challenge_with_mfa",
"limit_access_scope",
"alert_user",
"log_detailed_session"
],
"detection": {
"distance_km": 500,
"time_hours": 2
}
},
"data_exfiltration_attempt": {
"actions": [
"block_transfer",
"quarantine_user",
"immediate_security_review",
"preserve_forensic_data"
],
"indicators": [
"large_download",
"unusual_hours",
"unapproved_destination"
]
}
}
Best Practices
1. Start with Visibility
Before enforcing policies:
- Monitor existing access patterns
- Identify legitimate use cases
- Understand business workflows
2. Implement Gradually
Roll out in phases:
- Week 1-2: Deploy connectors, visibility only
- Week 3-4: Enable monitoring and alerting
- Week 5-6: Enforce policies for non-critical apps
- Week 7-8: Full enforcement for all applications
3. User Education
Zero trust requires user buy-in:
- Explain the "why" behind changes
- Provide clear documentation
- Offer training sessions
- Establish support channels
4. Continuous Improvement
Zero trust is not set-and-forget:
- Review policies quarterly
- Adjust based on new threats
- Update device requirements
- Refine access patterns
Measuring Success
Track these key metrics:
Security Metrics:
- Reduction in security incidents
- Mean time to detect (MTTD)
- Mean time to respond (MTTR)
- Percentage of policy violations
Operational Metrics:
- User satisfaction scores
- Support ticket volume
- Time to provision access
- False positive rate
Business Metrics:
- Compliance audit results
- Insurance premium changes
- Cost of security operations
- Business enablement velocity
Common Challenges and Solutions
Challenge 1: Legacy Applications
Problem: Old applications don't support modern authentication.
Solution:
- Use OneDot SASE's application connector
- Implement step-up authentication
- Plan for application modernization
Challenge 2: User Friction
Problem: Too many authentication prompts frustrate users.
Solution:
- Implement adaptive authentication
- Use device certificates for trusted devices
- Enable SSO across applications
- Set appropriate session timeouts
Challenge 3: Performance Concerns
Problem: Security checks add latency.
Solution:
- Deploy SASE points of presence near users
- Use intelligent caching
- Optimize policy evaluation
- Monitor and tune performance
Conclusion
Building a zero-trust network with OneDot SASE is a journey, not a destination. By following this guide, you can systematically implement zero-trust principles while minimizing disruption to your organization.
The key is to:
- Start with clear objectives
- Implement incrementally
- Monitor continuously
- Adjust based on learnings
With OneDot SASE, you have a powerful platform that makes zero trust achievable for organizations of any size.
Need help planning your zero-trust implementation? Contact our security experts for a free consultation.
