Security & Compliance

The ProjectFoodBox Application Portal (“the Portal”) is an internal, web-based launcher that presents the organization’s web applications as a filterable catalog of tiles. Anonymous users browse and launch applications; authenticated administrators manage the catalog, groups, single sign-on configuration, and usage statistics through a protected back office.

What the Portal is: a directory / navigation layer. What the Portal is not: a system of record. It holds no health, financial, or personal records. All sensitive workloads are handled by the destination applications, not by the Portal.

The Portal is built around the principle of data minimization. The complete set of data it stores is:

• Application catalog metadata — application names, descriptions, group tags, and destination URLs (bilingual EN/ES). Non-personal, non-sensitive.
• Group / category definitions — labels used to filter the catalog.
• Aggregate usage events — a timestamp, the tile/button interacted with, and the source IP address, recorded to produce anonymous usage statistics and to support security controls. These events are not linked to any named individual and contain no health information.
• Administrator accounts — a username and a one-way cryptographic password hash (passwords are never stored in plaintext). Applicable only to a small number of privileged staff, not to end users.
• Configuration settings — e.g., SSO parameters and access-control settings.

No PHI. No end-user PII. Because the Portal neither receives nor stores PHI/ePHI, it falls outside the scope of systems that require ePHI-specific controls under the HIPAA Security Rule. The only identifier processed is a source IP address, retained transiently for security and aggregate analytics and never correlated with health data or personal identity.

Privacy by design. The Portal runs no advertising, behavioral-tracking, or third-party analytics SDKs, and performs no user profiling. Anonymous visitors are assigned no cookies whatsoever; the only cookie used is a single functional, HttpOnly session cookie issued to authenticated administrators.

• Encryption in transit. All traffic is served exclusively over HTTPS. Plaintext HTTP requests are permanently redirected (HTTP 301) to HTTPS. TLS is restricted to modern versions (TLS 1.2 and TLS 1.3) with a strong, industry-standard cipher suite.
• Managed certificates.TLS certificates are issued by a public certificate authority (Let’s Encrypt) and renewed automatically before expiry.
• Geographic access restriction. Inbound access is filtered at the network edge to the United States and Argentina only; requests originating from other countries are refused before reaching the application.
• IP allow-list “lockdown” mode. Administrators can enable an allow-list that restricts the entire Portal to a defined set of IP addresses or CIDR ranges (for example, a corporate VPN), blocking all other traffic.
• Reverse proxy isolation. A hardened reverse proxy terminates TLS and is the only component exposed to the network; the application server and database are not directly reachable from the internet.

• Least privilege. Catalog browsing is public (non-sensitive data only). All management functions live behind an authenticated administrator boundary.
• Authenticated sessions. Administrator sessions use self-contained, encrypted and authenticated cookies (AES-256-GCM). Cookies are HttpOnly and, in production, flagged Secure so they are transmitted only over HTTPS.
• Session expiry. Administrator sessions automatically expire after 24 hours, requiring re-authentication.
• Enterprise SSO.Optional Microsoft Entra ID (Azure AD) single sign-on is supported, with CSRF-protected OAuth 2.0 authorization-code flow, allowing centralized identity, conditional access, and MFA to be enforced by the organization’s identity provider.
• Credential protection.Administrator passwords are stored only as one-way cryptographic hashes; plaintext credentials are never persisted. Every privileged API route independently verifies the caller’s session before acting.
• Account management. Administrators can be provisioned and de-provisioned, and passwords rotated, through the back office; the system prevents deletion of the last remaining administrator to avoid lock-out.

• Brute-force resistance. The authentication endpoint is rate-limited at the edge, and a host-level intrusion-prevention service (fail2ban) automatically bans source IPs that exhibit repeated failed logins or rate-limit abuse.
• Parameterized data access. All database access uses parameterized queries, mitigating SQL injection.
• Validated file uploads. Media uploads are restricted by file type and size, are stored with system-generated names outside the web root, are served with X-Content-Type-Options: nosniff, and are protected against path-traversal.
• Reduced attack surface. Diagnostic tooling that could reveal system internals is disabled by default and gated behind an explicit administrator setting.
• Modern framework. The Portal is built on a current, actively maintained web framework (Next.js) and runtime, enabling timely security patching.

• Containerized deployment. The application and database run as isolated containers. The database listens only on the local loopback interface and is never exposed to the public network.
• Host firewalling. Automated firewall rules (fail2ban) block abusive hosts; cloud-level network security groups provide an additional perimeter.
• Least-privilege runtime. The application container runs as a non-root user.
• Backups. Point-in-time snapshots of the database and application state can be produced on demand and retained according to organizational policy.

• Access logging. The reverse proxy records access logs (source IP, request, status) used for security monitoring and abuse detection.
• Usage auditing. Administrative statistics provide an audit view of catalog usage (interactions per application, per source IP, over time).
• Automated response. Intrusion-prevention monitors logs continuously and reacts to malicious patterns without manual intervention.

The Portal is designed so that it is not a conduit for, nor a repository of, PHI/ePHI. Because it neither creates, receives, maintains, nor transmits PHI, the Portal is generally outside the scope of the electronic-PHI safeguards mandated by the HIPAA Security Rule. Nonetheless, the organization applies HIPAA-aligned safeguards to the Portal as defense-in-depth:

• Administrative safeguards — role separation between anonymous and administrative access, workforce access management (provisioning/de-provisioning), and audit review of usage logs.
• Physical safeguards— hosting within controlled cloud infrastructure with the provider’s physical and environmental protections.
• Technical safeguards — unique user identification and authentication, automatic session termination, encryption in transit, integrity protection via authenticated session tokens, and audit logging.

Should the Portal’s role ever change such that PHI is introduced, a formal risk analysis, Business Associate Agreements (BAAs) where applicable, and the full set of Security Rule controls would be required prior to that change.

The Portal’s controls are designed to align with the objectives of relevant HITRUST CSF control domains. This alignment describes engineering practices; it is not, by itself, a HITRUST certification of the Portal.

• Access Control & Identity — authenticated administrative boundary, SSO support, session expiry, least privilege.
• Transmission Protection — enforced TLS 1.2/1.3, HTTPS-only.
• Network Protection — reverse-proxy isolation, geographic filtering, IP allow-list, database network isolation.
• Audit Logging & Monitoring — access and usage logging with automated intrusion prevention.
• Configuration & Vulnerability Management — hardened defaults, disabled diagnostics, maintained framework for timely patching.
• Data Protection & Privacy — data minimization; no PHI/PII; no third-party tracking.

The Portal provides navigation only. Authentication, authorization, and compliance for each linked application — including any that process PHI or PII — are the responsibility of that application and its owners. Users are directed to the destination application’s own security and privacy controls once they follow a link.

This document describes technical and organizational measures as implemented at the date shown above and is provided for informational purposes only. It is not a warranty, guarantee, certification, or legal attestation of compliance with HIPAA, the HITRUST CSF, or any other framework, and it does not create any contractual obligation. Formal compliance determinations require independent assessment by qualified auditors and the organization’s compliance and legal teams. Security is continuously reviewed and these measures may be updated without notice.