Corvus DM Security Architecture

Encryption at Rest

• Database — Amazon RDS uses AES-256 encryption via AWS Key Management Service (KMS). All data, automated backups, read replicas, and snapshots are encrypted.
• File storage — Amazon S3 objects are encrypted using server-side encryption (SSE-S3 or SSE-KMS). Each object is encrypted with a unique key, which is itself encrypted with a regularly rotated master key.
• Session tokens — JWT session tokens are signed with HMAC-SHA256 using a per-environment secret. Tokens are stored in HttpOnly, Secure, SameSite cookies and are inaccessible to client-side JavaScript.

Encryption in Transit

• HTTPS everywhere — all traffic is served over TLS 1.2 or 1.3 via AWS Certificate Manager certificates on the Application Load Balancer. HTTP requests are redirected to HTTPS.
• Database connections — Prisma ORM connects to PostgreSQL over SSL/TLS (sslmode=require).
• Email — Amazon SES uses TLS for outbound email delivery.
• Strict-Transport-Security — enforced via security headers to prevent protocol downgrade attacks.

Authentication Flow

• Primary SSO — Amazon Cognito User Pools with hosted UI. Supports SAML, OIDC, and social identity providers for institutional SSO integration.
• Session management — JWT tokens signed with HMAC-SHA256, stored in HttpOnly Secure cookies. Tokens are verified on every request by edge middleware before reaching application code.
• Password policy — enforced via Cognito: minimum 8 characters, mixed case, numbers, special characters. Brute-force protection with account lockout after repeated failures.

Multi-Factor Authentication (MFA)

• TOTP-based MFA — users enroll with an authenticator app (Google Authenticator, Microsoft Authenticator, Authy, or any TOTP-compatible app).
• Enforcement level — configurable per environment. Client environments are set to Required, meaning all users must enroll in MFA on first login.
• SMS fallback — optional SMS-based verification via Amazon SNS for users without an authenticator app.
• Handled by Cognito — MFA challenges are managed by the Cognito hosted UI before the user is redirected to the application. No MFA codes are processed by application code.

Session Security

• Cookies are HttpOnly (no JavaScript access), Secure (HTTPS only), and SameSite=Lax (CSRF protection).
• Session secrets are unique per environment, so a compromised secret in one environment does not affect others.
• Impersonation sessions are logged separately with mandatory reason fields and are included in the audit trail.

Role-Based Access Control (RBAC)

Every user is assigned a role that determines their permissions across the system. Permissions are checked server-side on every API request. Client-side UI enforcement is a convenience layer and not a security boundary.

Access Policies

• Configurable access duration per audience and content scope (e.g., alumni access expires after 24 months).
• Download permissions are separately controllable, allowing view-only access to be enforced for sensitive content.
• Student data is scoped to the student's own records. Faculty only see students assigned to their committee.

Application Audit Trail

Every significant action in the system is recorded as an immutable AuditEvent with:

• Who — the user ID and role of the actor
• What — the action type (login, create, update, delete, approve, score, impersonate, export, etc.)
• When — ISO 8601 timestamp
• Where — the resource type and resource ID affected
• Context — additional metadata (IP address, user agent, before/after values where applicable)

Logged Actions Include

• User login and logout (including failed attempts)
• Document uploads, views, and downloads
• Scoring and feedback submissions
• Milestone status changes and approvals
• Committee assignments and changes
• User creation, modification, and deprovisioning
• Impersonation sessions (start/end, reason, actions performed)
• Data exports and API access
• Configuration changes (settings, policies, retention rules)
• Forum moderation actions (flags, resolutions, category changes)

Infrastructure Logging

• AWS CloudWatch — container logs, application errors, and performance metrics from ECS.
• ALB Access Logs — every HTTP request to the load balancer is logged with client IP, request path, response code, and latency.
• RDS Audit Logs — database query logging available for compliance investigations.
• S3 Access Logs — file access is logged at the bucket level.

Retention

Audit logs are retained for the lifetime of the environment. They are included in archive packages when a student is archived and are never purged while the environment is active.

Edge Security (Middleware)

A server-side middleware layer runs on every request before it reaches application code, enforcing multiple security controls:

• Bot blocking — known scanner and exploit tool user agents (sqlmap, nikto, nmap, masscan, nuclei, gobuster, etc.) are blocked with 403 responses.
• Exploit path blocking — requests to known exploit paths (/cgi-bin, /shell, /cmd, /etc/passwd, /.aws, etc.) return 404.
• Directory traversal prevention — requests containing .. or encoded traversal sequences are blocked.
• Session verification — protected routes require a valid JWT session cookie, verified using HMAC-SHA256 before the request is forwarded.

Security Headers

Every response includes the following security headers:

DDoS Protection

AWS Shield Standard is enabled by default on all ALB and Route 53 resources, providing protection against common DDoS attack vectors (SYN floods, UDP reflection, etc.) at no additional cost.

Ownership

Ownership of data and intellectual property is clearly separated between the client institution and Corvus Software Group.

• Client data — all user-related data entered into the environment is owned exclusively by the university. This includes student records, faculty profiles, uploaded documents, forum content, committee assignments, milestones, scores, feedback, audit logs, and any other data created by or about the institution's users. Corvus Software Group makes no claim to this data.
• No data mining — Corvus Software Group does not access, analyze, sell, share, or otherwise mine client data for any purpose. Client data is used solely to provide the application's functionality to the institution and its authorized users.
• Application codebase — the Corvus DM software, including all source code, architecture, design, and proprietary algorithms, is the intellectual property of Corvus Software Group. The client is granted a license to use the application for the duration of the agreement.

Data Portability & Destruction

• The university may export its data at any time using the built-in data export tools (CSV, JSON, ZIP formats).
• At the end of an evaluation period, the client chooses: transition to production (keep everything) or secure destruction (all data, files, backups, and logs are permanently deleted).
• Destruction includes: RDS instance deletion (with final snapshot if requested), S3 bucket emptying and deletion, Cognito User Pool deletion, and CloudWatch log group deletion.
• Upon request, Corvus Software Group will provide written confirmation that all client data has been destroyed.

FERPA (Family Educational Rights and Privacy Act)

• Student educational records are accessible only to the student, their assigned committee, and authorized administrators.
• All access to student records is logged in the audit trail.
• Impersonation requires a documented reason and is fully audited.
• Forum categories can display FERPA banners reminding users not to share protected information.
• Data export is restricted to authorized admin roles and logged.
• Legal hold functionality freezes student data and generates tamper-evident archive packages.

AWS Compliance Inheritance

By running on AWS, Corvus DM inherits the following infrastructure compliance certifications:

• SOC 1, SOC 2, SOC 3 (Service Organization Control)
• ISO 27001, ISO 27017, ISO 27018 (Information Security Management)
• FedRAMP (Federal Risk and Authorization Management Program)
• HIPAA (Health Insurance Portability and Accountability Act) eligible
• PCI DSS Level 1 (Payment Card Industry)
• CSA STAR (Cloud Security Alliance)

Data Processing

• Corvus Software Group acts as a data processor. The client institution is the data controller.
• A Data Processing Agreement (DPA) or Business Associate Agreement (BAA) is available upon request.
• Data residency: all data is stored in AWS US-West-2 (Oregon). Alternative regions are available upon request.