Security Centre
Security Audits & Bulletins
Transparency Reports Detailing The Technical Resilience Of The ISMS Infrastructure — Multi-Layer Security, TLS 1.3, JWT Auth & Penetration Testing.
ISMS Security Posture: Active
All ISMS Core Systems — ERP Admin Portal, Staff App, Parents App — Are Protected By Multi-Layer Security Architecture Including TLS 1.3 Transport, JWT Session Management, Role-Based Access Controls, And Dedicated Server Infrastructure With 99.9% SLA.
01 System Uptime Guarantee
We Do Not Use Cheap Shared Hosting. All ISMS Data Is Routed Through High-Performance Dedicated Servers Customized For Our Code Schemas. We Deliver A Standard 99.9% Uptime SLA For The Core Portal API Arrays Ensuring Fluid Synchronization Between Mobile Apps And The Web Dashboard.
Our Infrastructure Is Provisioned On Dedicated Physical Servers — Not Shared VMs — To Ensure Performance Isolation During High-Load Events Such As Statewide Exam Result Releases Or Annual Fee Collection Cycles.
| Service Component | SLA Target | Monitoring |
|---|
| ERP Admin Portal API | 99.9% Monthly | 24/7 Automated Health Checks |
| Parents App Data Endpoints | 99.9% Monthly | Response-Time Probes Every 60s |
| Staff App REST API | 99.9% Monthly | JWT Validity + Endpoint Ping |
| Database Read Cluster | 99.95% Monthly | Replication Lag Monitoring |
| School Verification Registry | 99.9% Monthly | Certificate Status Checks |
Dedicated Server Architecture
ISMS Runs On Dedicated Bare-Metal Servers With Isolated Network Segments. No Other Tenant Shares Our Compute Or Memory Resources — Eliminating Noisy-Neighbor Performance Degradation During Peak Academic Seasons.
02 Authentication & Access Security
Every Access Point In The ISMS Ecosystem Is Protected By Time-Bounded JSON Web Tokens (JWT). Sessions Are Scoped To Specific Roles And Expire Automatically To Prevent Unauthorized Re-Use Of Stolen Credentials.
- JWT RS256 Tokens: Asymmetrically Signed Access Tokens With Short Expiry Windows — Server-Side Key Rotation On A Rolling Schedule.
- Role-Based Access Control (RBAC): Admin, Principal, Teacher, Non-Teaching Staff, And Parent Roles Each Carry Strictly Scoped Permission Sets — No Role Escalation Paths Exist By Design.
- Brute-Force Rate Limiting: Login Endpoints Apply Exponential Backoff — Too Many Failed Attempts Temporarily Locks The IP And Notifies The Admin.
- Password Hashing: All User Passwords Are Hashed via bcrypt With Salting — Plaintext Passwords Are Never Stored Or Logged Anywhere In The System.
- Session Invalidation: Manual Logout Or Token Expiry Immediately Invalidates The Session Server-Side — Force Re-Authentication Required For Any Subsequent Access.
- Device-Scoped Sessions: Each Device Login Generates A Fresh Token — Logging Into A New Device Does Not Automatically Invalidate Existing Active Sessions Unless Explicitly Requested.
03 Cryptographic Transport Protocols
Routine Penetration Testing Sweeps Are Executed Monthly Against Our API Endpoints. At Rest, All Central Databases Employ AES-256 Block Encryption Equivalents. In Transit, Our Android App Endpoints Firmly Reject Any Downgraded HTTP Connections, Mandating Strict TLS 1.3 Handshake Verification Before Transmitting Encrypted JSON App Payloads.
| Layer | Protocol / Algorithm | Implementation |
|---|
| Transport Security | TLS 1.3 Mandatory | Plain HTTP Connections Rejected With 301 Redirect To HTTPS |
| At-Rest Encryption | AES-256-GCM | Database Storage Volumes Encrypted At Block Level |
| Token Signing | HMAC-SHA256 / RS256 | JWT Access & Refresh Token Pairs |
| Android Credential Storage | EncryptedSharedPreferences | Android Keystore-Backed Secure Credential Vault |
| API Certificate Pinning | X.509 Certificate Validation | Mobile Apps Validate Server Certificate Fingerprint On Connect |
| Password Hashing | bcrypt (cost=12) | Adaptive Cost Factor — Computationally Expensive For Brute-Force |
Zero Plaintext Policy
ISMS Core Has A Strict "Zero Plaintext" Policy. Credentials, Tokens, And Sensitive Academic Records Are Never Serialized Or Logged In Plaintext At Any Layer — Transport, Application, Or Storage.
04 Infrastructure Security
The ISMS Backend Is Containerized Using Docker And Served Behind A Battle-Hardened Nginx Reverse Proxy. Multiple Security Layers Protect The Server Before Any Request Reaches Application Code.
- Nginx Reverse Proxy: All Traffic Passes Through Nginx First — Malformed Requests, Oversized Bodies, And Invalid Headers Are Rejected Before Reaching Django.
- Rate Limiting Per IP: Nginx Applies Strict Rate Limits On All API Zones — Burst Limits Prevent Automated Scraping And DDoS Amplification Attempts.
- Content Security Policy (CSP): Strict CSP Headers Prevent XSS, Clickjacking, And Inline Script Injection Across All Web Portal Pages.
- Docker Container Isolation: Backend, Database, And Web Services Run In Isolated Docker Containers — A Compromise In One Cannot Laterally Move To Another Without Network Boundary Traversal.
- Automated Encrypted Backups: Full Database Backups Are Automated Via Shell Scripts — Encrypted Before Storage, With Retention Windows For Business Continuity.
- Security Headers Enforced: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy Are Sent On All Responses — Preventing A Broad Class Of Web-Layer Attacks.
05 Data Isolation Architecture
Every School That Deploys ISMS Core Operates In A Logically Isolated Data Environment. No School Can Access Another School's Records — Isolation Is Enforced At The Database Query Level Via School Code Scoping On Every API Call.
- School Code Scoping: Every Database Query Is Filtered By The Authenticated School Code — Cross-Tenant Data Access Is Architecturally Impossible Without A Valid School-Specific Token.
- No Shared User Tables: Student, Staff, And Parent Records Exist Only Within The Namespace Of Their Registered School — No Global User Registry That Could Be Scraped.
- No Third-Party Analytics: Zero Integration With Google Analytics, Facebook Pixel, Or Any External Data Brokers — School Data Never Leaves Our Controlled Infrastructure.
- API Response Filtering: All API Responses Are Serialized Through Strict Field-Level Allowlists — Internal Database Fields Are Never Accidentally Exposed To Client Applications.
School Data Ownership
Durgaai Solutions Acts Purely As The Technology Vendor. All Academic Data (Marks, Fees, Attendance) Belongs Exclusively To The Registered Institution. We Do Not Sell, License, Or Share School Data With Any Third Party.
06 Penetration Testing & Monitoring
ISMS Core Undergoes Regular Security Assessment Cycles To Proactively Identify And Remediate Vulnerabilities Before They Can Be Exploited.
- Monthly API Pen Tests: Internal Penetration Testing Sweeps Are Run Monthly Against All REST API Endpoints — Authentication Boundaries, Input Validation, And Business Logic Are Tested Systematically.
- Automated SAST Scans: Static Analysis Security Testing Is Integrated Into The CI/CD Pipeline — Code Changes Are Scanned For Injection Vectors And Insecure Patterns Before Deployment.
- Real-Time Error Monitoring: Server Exceptions And Unusual Request Patterns Trigger Real-Time Alerts To The Security Operations Team For Immediate Triage.
- Log Retention Policy: Access Logs Are Retained For 90 Days — Providing Adequate Historical Depth For Incident Response And Forensic Analysis Without Excessive Data Accumulation.
- Dependency Patching: Python And NPM Dependencies Are Reviewed For CVEs On A Monthly Cycle — Critical Patches Are Applied Within 48 Hours Of Disclosure.
07 Vulnerability Disclosure Program
We Welcome Responsible Security Research And Appreciate Ethical Disclosures From The Security Community. If You Discover A Vulnerability In The ISMS Ecosystem, We Ask That You Follow Our Responsible Disclosure Guidelines.
- Report Channel: Email security@durgaaisolutions.in With A Detailed Technical Description Of The Vulnerability.
- Include In Report: Steps To Reproduce, Affected Component, Potential Impact Assessment, And Any Proof-Of-Concept (Non-Destructive Only).
- Response SLA: We Acknowledge All Genuine Vulnerability Reports Within 72 Business Hours And Provide A Remediation Timeline Within 7 Working Days.
- Safe Harbor: Security Researchers Who Follow This Disclosure Policy Will Not Face Legal Action Provided They Do Not Access, Modify, Or Exfiltrate Real School Data.
- Out Of Scope: Social Engineering, Physical Security Attacks, And Denial-Of-Service Testing Are Explicitly Out Of Scope And Will Not Be Treated As Responsible Disclosures.
08 Security Bulletins (2026)
This Log Records All Security Events, Patches, And Proactive Hardening Measures Applied To The ISMS Production Environment.
- June 2026: Upgraded All API Authentication Middleware To Enforce Strict JWT Audience Claim Validation. Previous Behavior Accepted Tokens Without Audience Binding. (Resolved: Severity Medium)
- May 2026: Added HTTP Security Headers (HSTS, CSP, X-Frame-Options) Across All Web Portal Routes. Closes Potential Clickjacking And XSS Injection Surface. (Resolved: Severity Low)
- April 2026: Nginx Rate Limiting Zones Expanded To Cover Authentication, Verification, And Data Export Endpoints Separately — Prevents Category-Specific DDoS Exhaustion. (Resolved: Proactive Hardening)
- March 2026: Patched Sub-Millisecond Lag In Token Rotation Arrays For Teacher Portals. Refresh Token Reuse Window Was Wider Than Intended. (Resolved: Severity Low)
- February 2026: Successfully Absorbed Synthetic DDoS Simulations Testing Our CloudFlare Thresholds Ahead Of Statewide Exam Result Declarations. Infrastructure Held Within SLA. (Status: Passed)
- January 2026: Performed Full Dependency Audit — Updated 6 Python Packages With Known CVEs (All Low-Severity). Automated Dependabot Alerts Now Active. (Resolved: Severity Low)
Current Security Status: All Systems Nominal
No Active High Or Critical Severity Vulnerabilities Exist In The ISMS Production Environment As Of The Date Of This Bulletin. The Security Team Continues Proactive Monitoring 24/7.