a zero trust mapping

1. Zero Trust Protect Surface
Mapping – Donation Platform
Made by Anas aldweik, Saeed Latif, Vidhi, Ammar Salmway
Prof handrow

2. Table of
Contents
1.Data Element
2.Application Element
3.Assets Element
4.Services Element
5.References

3. Data Element
The platform stores and manages multiple types of
sensitive data that require protection under the Zero
Trust model.
Types of Data:
• Personally Identifiable Information (PII): Full name,
email address, phone number
• Identity verification documents: Uploaded images or
scanned IDs
• Donation history: Includes timestamps, item
descriptions, donor info
• Background check results returned via Azure Function

4. Data Element cont.
Key Security Requirements:
• Encrypt all sensitive data both at rest (MySQL encryption) and in transit
(TLS/SSL)
• Store PII and uploaded documents in segregated storage zones with
limited access
• Apply strict, role-based access controls so users can only access their
own data
• Monitor and log every access attempt to data (successful or failed) with
alerts on abnormal behavior
• Regularly audit access logs and perform data classification reviews to
ensure proper tagging and control
Zero Trust assumes attackers may already be inside the network, so data is
always treated as sensitive and never implicitly trusted.

5. Application Element
The application is a Flask-based web app that handles user sessions, verification, and
donation functionalities. It is deployed using Azure App Service with a secure and
scalable cloud-native configuration.
Hosting Platform: Azure App Service
• Fully Managed Hosting: Handles patching, scaling, and maintenance
automatically
• Quick Deployment: Code is pushed directly from GitHub or VS Code
• Built-in Flask Support: Works with Python, WSGI (Gunicorn), and custom startup
commands
• Secure Deployment: Supports HTTPS by default and integrates with Azure security
features
• Environment Variables: Used to securely store DB credentials and API keys
• SSH Access: Enables live troubleshooting and file verification post-deployment

6. Application Element cont.
Security Requirements:
• Enforce strong password policies and enable Multi-Factor Authentication (MFA)
• Use HttpOnly, Secure, and SameSite attributes in cookies for secure session
management
• Protect all forms and routes with CSRF tokens (via Flask-WTF)
• Sanitize and validate all user input to prevent injection attacks (SQLi, XSS)
• Implement session timeout and idle expiration to reduce session hijacking
risks
• Require re-authentication for critical actions like changing email or accessing
sensitive info
Under Zero Trust, every action—even from authenticated users—is subject to
validation and context-based enforcement.

7. Assets Element
Assets include all infrastructure components required to
host and run the application.
Assets Identified:
• Azure App Service (hosting Flask application)
• Azure MySQL Database (for persistent storage)
• Azure Blob Storage or local directory for file uploads
• Client devices (browsers, mobile devices)

8. Assets Element cont.
Security Requirements:
• Maintain an up-to-date inventory of all active resources within Azure
portal
• Harden configurations: restrict access, enforce TLS, apply OS/app
patches when applicable
• Apply network security groups and host-based firewalls to restrict traffic
• Use micro-segmentation within Azure: isolate the DB using VNet rules
• Treat all internal assets as untrusted: use authentication between
services
• Enable Azure Monitor and Application Insights for logging and resource
health
The Zero Trust model assumes breach—every server, client, and resource is
considered a potential attack vector.

9. Services Element
This element includes external or internal services used by
the application, especially those that cross trust boundaries.
Services Used:
• Azure Function: Performs user background verification
• Azure MySQL Database: Stores all user and platform data
• Azure Blob Storage or equivalent: Hosts uploaded
identity verification files

10. Services Element cont.
Security Requirements:
• Encrypt all communication using TLS (Functions, DB, Blob)
• Authenticate and authorize every service request; use API keys or Azure-
managed identities
• Never expose services publicly unless explicitly required and protected
• Use least-privilege principles for access policies (e.g., SQL users, blob
access tokens)
• Implement logging for all service use with alerting for unusual patterns
• Validate responses from external services before granting trust or
permissions
Each external or cloud-native call must be validated independently, with no
trust based on internal location or assumed safety.

11. References
1. Executive Order 14028: Improving the Nation's
Cybersecurity. The White House; 2021. Available
from: https://www.whitehouse.gov
2. Cybersecurity and Infrastructure Security
Agency (CISA). Zero Trust Maturity Model v2.
2023. Available from: https://www.cisa.gov
3. Flask Project. Security Documentation. Available
from: https://flask.palletsprojects.com/
4. Microsoft Azure. Security Best Practices.
Available from:
https://learn.microsoft.com/en-us/azure/securit
y/
5. Microsoft Azure. App Service Documentation.
Available from:
https://learn.microsoft.com/en-us/azure/app-se
rvice/
6. Kindervag J. Zero Trust Architecture Explained.
NetSecurity. Available from:
https://netsecurity.com
7. National Institute of Standards and Technology.
Special Publication 800-207: Zero Trust
Architecture. Available from:
https://csrc.nist.gov