Zero Trust for Applications¶
The Zero Trust methodology has been around for a while, and many organisations have been implementing Zero Trust principles. When considering applications deployed in an enterprise, organisations typically implement zero trust at the infrastructure layer, protecting access to and from applications and securing network communications.
Infrastructure-level protection is essential, but there's another threat vector: the application itself. While SDLC processes and security tools help secure code, there's an opportunity to implement Zero Trust principles directly within applications.
What is ZT4A?¶
Zero Trust for Applications is a concept I am proposing for the secure development of applications. Just like traditional Zero Trust, ZT4A is a methodology, mindset, and approach to application development and software security. I see it as a methodology that complements existing SDLC processes rather than replacing them.
ZT4A Comparison¶
Pillar | Description | Key Components |
---|---|---|
Identity | Secure authentication and authorization | Role-based access, MFA. |
Devices | Endpoint security and device management | Device compliance, endpoint detection, device trust. |
Network | Network segmentation and access control | Micro-segmentation, network monitoring, secure connections |
Applications | Application security and access control | Application-level security, API protection, secure coding. |
Data | Data protection and governance | Privacy, encryption/decryption by role, data retention policies. |
Infrastructure | Infrastructure security and monitoring | Cloud security, infrastructure monitoring, secure configurations. |
Maturity Levels¶
ZT4A implementation follows a maturity progression:
- Basic ⭐: Core security controls implemented, manual processes acceptable
- Intermediate ⭐⭐: Automated enforcement, integrated monitoring, risk-based controls
- Advanced ⭐⭐⭐: Continuous adaptation, AI-enhanced detection, full integration with DevSecOps
Pillars¶
ZT4A has a similar pillar structure to Zero Trust. We break it down as follow
Identity¶
The Identity pillar ensures secure authentication and authorisation, by ensuring only the right user logs on, and continuously monitoring the session for compromise.
Objective | Control | ML | Requirement |
---|---|---|---|
Strong Authentication | Phishing resistant MFA | ⭐ | The application is using MFA for authentication. |
Compromised password monitoring | ⭐⭐ | The password used to authenticate was validated against a breached credential service. | |
Session Management | Risk-based session timeout | ⭐ | Session timeout based on risk level: 30+ minutes for low-risk, 10-15 minutes for high-risk operations. |
Session validation | ⭐ | Validate the session against originating IP, and User Agent. | |
Cross Site Request Forgery | ⭐⭐ | Validate each interaction has originated from the app with CSRF tokens. | |
Role Based Access | Principle of least privilege | ⭐ | Users are assigned minimum necessary roles with proper role composition for complex scenarios. |
Regular Role membership reviews | ⭐⭐ | Role owners are reviewing and validating members on a defined frequency (at least once per year). |
Devices¶
Objective | Control | ML | Requirement |
---|---|---|---|
Session Management | Limited data stored locally | ⭐ | Use secure storage, avoid cookies. Only store session tokens. |
Secure token management | ⭐⭐ | Use sliding window expiration or refresh token patterns with appropriate rotation intervals. |
Networks¶
Objective | Control | ML | Requirement |
---|---|---|---|
Secure Network | SSL/TLS | ⭐ | The application requires SSL/TLS on the webserver. |
Database communication | Secure TLS/SSL communication to the database | ⭐⭐ | The application must use TLS/SSL for all database communications. |
Code Injection | Application WAF | ⭐⭐⭐ | Implement an Application WAF to block all unsanitised code |
Application¶
Objective | Control | ML | Requirement |
---|---|---|---|
Secure coding | No application vulnerabilities | ⭐ | Application is free of vulnerabilities (SAST & DAST). |
Supply Chain Security | Dependency validation | ⭐ | All dependencies are scanned for vulnerabilities and have verified SBOMs. |
Rate Limit | Prevent Brute Force | ⭐⭐ | The application has a brute force prevention mechanism. |
API Control | Strong authentication | ⭐⭐⭐ | APIs use secure authentication mechanisms (OAuth2/OIDC with proper JWT validation, mTLS, or API key/secret with rotation). |
Data¶
Objective | Control | ML | Requirement |
---|---|---|---|
Encryption | Database encryption | ⭐ | The database is encrypted at rest. |
Field encryption | ⭐⭐ | Sensitive fields are encrypted. | |
Data Retention | Data Retention policy | ⭐⭐ | What data to keep and what data to delete is strictly enforced. |
Version Control | Version control on all records | ⭐⭐⭐ | All records are stored for historical and audit purposes. |
Retention | Soft-delete of records | ⭐⭐⭐ | Only soft delete records for a specified time before actually deleting it. |
Infrastructure¶
Objective | Control | ML | Requirement |
---|---|---|---|
Logging | Activity tracking | ⭐ | Keep track of all activities in a local log database |
SIEM integration | ⭐⭐ | Application logs are forwarded to the SIEM. | |
Up-to-date platform | No infrastructural vulnerabilities | ⭐ | All components are free of exploitable vulnerabilities. |
Incident Response | Automated response capabilities | ⭐⭐ | Integration with incident response procedures and automated threat response. |
Metrics & Monitoring | ZT4A effectiveness metrics | ⭐⭐⭐ | KPIs for authentication success rates, session anomalies, and security control effectiveness. |
Framework Integration¶
ZT4A complements existing security frameworks:
- NIST Cybersecurity Framework: Maps to Identify, Protect, Detect, Respond, and Recover functions
- OWASP ASVS: Provides detailed verification requirements for web applications
- SAMM: Integrates with software assurance maturity model practices
- DevSecOps: Embeds security controls into CI/CD pipelines
Legacy Application Considerations¶
For applications that cannot fully meet ZT4A requirements:
- Risk Assessment: Document gaps and implement compensating controls
- Phased Migration: Prioritise high-impact, low-effort improvements
- Network Segmentation: Isolate legacy systems with additional network controls
- Enhanced Monitoring: Increase logging and monitoring for systems with security gaps
Implementation Roadmap¶
- Assessment: Evaluate current application security posture against ZT4A pillars
- Prioritization: Focus on high-risk applications and quick wins
- Pilot Program: Implement ZT4A on new development projects
- Incremental Rollout: Apply to existing applications based on risk and business impact
- Continuous Improvement: Regular reviews and updates based on threat landscape changes