SHEPARD'S BEACON

A Platform of Shepard's Collective Ministries

PLATFORM SECURITY OVERVIEW

Published: April 3, 2026

Public Release | Version 2.0

✓ Our Security Commitment

Shepard's Beacon is built on a foundational belief: the people we serve — families of the missing, law enforcement partners, and community volunteers — deserve to know their information is handled with the highest standard of care.

This document describes the security measures that protect data on the Shepard's Beacon platform. It covers both the security controls we have built into the application itself and the infrastructure protections provided by our cloud hosting partner, Google Cloud Platform (GCP).

We distinguish clearly between these two layers throughout this document so you understand exactly what each provides.

ℹ How to Read This Document — Two Layers of Security

Shepard's Beacon operates on two distinct security layers:

GCP Infrastructure Layer: Security controls built into Google Cloud Platform by Google, available to all applications hosted on GCP. Shepard's Beacon benefits from these controls because we deploy on GCP — they are not certifications Shepard's Beacon itself holds.

Shepard's Beacon Application Layer: Security controls we have designed, built, and operate ourselves within the platform. These are specific to Shepard's Beacon and reflect deliberate architectural decisions made for this platform.

Both layers are important. Together, they form the security posture of the platform.

1. Introduction

Shepard's Beacon is a missing persons tracking and search coordination platform operated by Shepard's Collective Ministries, a Virginia-domiciled nonprofit ministry. The platform serves law enforcement agencies, authorized search and rescue organizations, families of missing individuals, and credentialed community volunteers.

Because missing persons cases involve sensitive personal information — including case records, location intelligence, identification imagery, and biometric data — security is not a feature of the platform. It is the foundation on which every other feature is built.

This document provides a plain-language overview of the security architecture protecting the platform, its users, and the individuals at the center of every case. It is written for a general public audience including families, partner organizations, and law enforcement agencies.

2. Infrastructure Security — Google Cloud Platform (GCP)

Shepard's Beacon is deployed on Google Cloud Platform, a major commercial cloud environment operated by Google. By hosting on GCP, our platform inherits a set of physical, network, and infrastructure security controls that Google maintains as part of its service.

ℹ Important Distinction

The certifications and controls described in this section belong to Google Cloud Platform — not to Shepard's Beacon. Shepard's Beacon is a customer of GCP. We benefit from Google's infrastructure security, but we do not independently hold certifications such as FedRAMP, SOC 2, or ISO 27001.

2.1 GCP Certifications (Google's, Available to Hosted Applications)

Google Cloud Platform maintains independent third-party certifications that apply to the infrastructure layer on which Shepard's Beacon runs. These include:

Security Control

How It Protects You

ISO 27001

International standard for information security management systems. Google's data center operations and cloud infrastructure are certified.

SOC 1, 2 & 3

Independent auditor reports covering security, availability, and confidentiality of Google's cloud infrastructure. Reports are available to customers under NDA.

FedRAMP

Google's infrastructure holds FedRAMP authorization. Shepard's Beacon does not independently hold FedRAMP authorization and is not a FedRAMP-authorized system.

PCI DSS

Google's infrastructure is PCI DSS compliant. This applies to Google's environment; Shepard's Beacon has not sought independent PCI certification.

CSA STAR

Cloud Security Alliance transparency certification for Google's cloud security controls.

These certifications mean that the physical and network infrastructure our platform runs on has been independently verified. They do not mean Shepard's Beacon has been audited against or certified under any of these frameworks.

2.2 Physical Data Center Security (Google-Operated)

All Shepard's Beacon data resides in Google-operated data centers. Google's physical security controls include:

• Custom-designed facilities with no external identification or public marking

• Multi-layer perimeter security including fencing, vehicle barriers, and security checkpoints

• Biometric access controls for data center entry by Google personnel

• 24/7 on-site security staffing and continuous video monitoring

• Secure hardware destruction for decommissioned storage media

Shepard's Beacon has no physical access to Google's data centers. These controls are entirely operated by Google.

2.3 Network Security (GCP-Provided)

GCP provides foundational network protections that Shepard's Beacon configures and uses:

• Virtual Private Cloud (VPC): Our services run within a private, logically isolated network. Database and internal services are not exposed to the public internet.

• Cloud Armor: Google's web application firewall and DDoS mitigation layer, applied to traffic entering the platform.

• TLS Termination at the Edge: All inbound traffic is decrypted and inspected at Google's network edge before reaching our application.

• Private Service Connect: Internal service-to-service communication routes over Google's private backbone rather than the public internet.

• Google Front End (GFE): Google's global load balancing layer absorbs and filters internet traffic before it reaches our application servers.

2.4 Encryption Provided by GCP

GCP encrypts all data stored on its infrastructure at rest by default, using AES-256. This applies to disks, storage buckets, and database volumes. Encryption key management is handled through Google Cloud Key Management Service (Cloud KMS). This encryption is provided automatically by GCP to all hosted applications, including Shepard's Beacon.

3. Application Security — Built by Shepard's Beacon

The following sections describe security controls that Shepard's Beacon has designed and implemented at the application layer. These are specific to our platform and are maintained by our development team.

3.1 Authentication

Shepard's Beacon uses a custom user model with email-based login and universally unique identifiers (UUIDs) for all user accounts. Authentication operates differently depending on how you access the platform:

• Web portal access uses Django's session-based authentication, with session cookies configured for HTTPS-only transmission and protection against cross-site request forgery (CSRF).

• Mobile app and API access uses JSON Web Tokens (JWT) with 30-minute access tokens and 7-day refresh tokens. Refresh tokens are rotated on each use and invalidated (blacklisted) after rotation, preventing replay attacks.

• All user passwords are validated against four security rules: minimum length of 8 characters, similarity check against personal information, rejection of commonly used passwords, and prevention of numeric-only passwords.

Multi-factor authentication (MFA) using time-based one-time passwords (TOTP), with SMS backup via Twilio, has been built into the platform and is ready to activate. MFA enforcement for administrative and law enforcement roles is a planned production configuration step.

3.2 Transport and Browser Security

When Shepard's Beacon runs in production mode, the following transport security settings are active:

Security Control

How It Protects You

HTTPS Enforcement

All HTTP requests are automatically redirected to HTTPS. Unencrypted connections are not accepted.

HSTS (1-Year)

HTTP Strict Transport Security is set to one year with subdomain coverage and preload eligibility, instructing browsers to always use HTTPS.

Secure Cookies

Session and CSRF cookies are transmitted over HTTPS only and are inaccessible to JavaScript running on the page.

SameSite Cookie Policy

Cookies use the 'Lax' same-site policy, restricting cross-origin cookie transmission and reducing CSRF exposure.

Clickjacking Protection

The X-Frame-Options header is set to DENY, preventing any page from being embedded inside an iframe on another site.

Content Type Protection

The X-Content-Type-Options: nosniff header prevents browsers from interpreting files as a different type than declared.

XSS Filter Header

The X-XSS-Protection header is enabled for legacy browser compatibility alongside Content Security Policy.

3.3 Content Security Policy (CSP)

A Content Security Policy restricts which external resources the platform's web pages may load, reducing the risk of cross-site scripting (XSS) attacks. The current policy allows scripts and styles from trusted CDNs (jsDelivr, Cloudflare, Google Fonts) in addition to the platform's own origin. Map tile imagery from OpenStreetMap, ArcGIS, and CartoDB is permitted for the geospatial features of the platform.

The current policy uses 'unsafe-inline' for scripts and styles, which is a known limitation. Tightening CSP to use nonce-based directives — eliminating 'unsafe-inline' — is a documented improvement on our security roadmap.

3.4 Role-Based Access Control (RBAC)

Access to every feature and piece of data on Shepard's Beacon is governed by a comprehensive role-based access control system. Every user is assigned a role, and every role carries a specific set of permissions. Users cannot access data or functionality outside their assigned permission level.

The platform defines eight user roles:

Security Control

How It Protects You

Super Administrator

Full platform governance. Permanent protected access. Assigns geographic boundaries to partner and LEO roles.

Administrator

Platform-wide case and user management.

Security Administrator

Security policy oversight, audit log access, and misuse detection review.

Partner Administrator

Management of a specific partner organization's cases and members.

Law Enforcement (LEO)

Full investigative access to assigned cases, including sensitive data and AI analysis outputs.

Case Initiator

Opens and manages cases for a missing person they have a verified relationship with.

Search Party Member

Mobile app only. Participates in authorized active search operations.

Registered User

Verified community member with tip submission access and limited case visibility.

Permissions are defined across ten action types (Create, Read, Update, Delete, Admin, Assign, Verify, Approve, Export, Moderate) and four scopes (Global, Case, Regional, Own-Only). This matrix is loaded from a controlled configuration file at deployment. Permissions are enforced at both the API layer and the database query layer, so access restrictions apply even if the application interface is bypassed.

Two additional middleware controls reinforce role boundaries:

• Mobile-Only Role Blocking: The Search Party Member and Registered User roles are restricted to the mobile application and cannot access the web portal.

• Pending Boundary Gate: Partner Administrator and LEO accounts are blocked from accessing any case data until a Super Administrator has assigned them a geographic jurisdiction.

3.5 API Rate Limiting

The platform applies multi-tier rate limiting to all API endpoints to protect against abuse, credential stuffing, and denial-of-service attempts. Limits are applied by role:

Security Control

How It Protects You

Anonymous (unauthenticated)

100 requests per hour

Burst limit (all users)

30 requests per minute

Super Administrator / Admin

10,000 requests per hour

Law Enforcement Officer

5,000 requests per hour

Search Party Member

3,000 requests per hour

Case Initiator

1,000 requests per hour

Registered User

500 requests per hour

Organizations may be granted configurable rate overrides where operationally necessary. Rate limit events are logged for security review.

3.6 Input Validation

All data submitted to the platform is validated before it is accepted. The platform's validation library covers:

• Phone numbers in E.164 format with US-specific rules

• Geographic coordinates and radius values

• Physical descriptors including height, weight with unit conversion, and age (0–120)

• Case numbers, license plates, and other structured identifiers

• Risk scores, probability values, and confidence ranges

• Social media URLs

• File uploads: strict file extension whitelist for images, video, audio, and documents

• Date validation (not-future dates, reasonable historical range)

Composite validators apply sets of these rules together when validating complete person profiles or location submissions, ensuring consistency across all case data entry points.

3.7 Webhook Security

Shepard's Beacon receives automated messages from Twilio (for SMS delivery) and Meta (for Messenger and Instagram integrations). Each incoming webhook is cryptographically verified before any processing occurs:

• Twilio webhooks: Verified using HMAC-SHA1 signature in the X-Twilio-Signature header, compared using a timing-safe function to prevent timing attacks.

• Meta Messenger and Instagram webhooks: Verified using HMAC-SHA256 signature in the X-Hub-Signature-256 header.

Webhook endpoints bypass standard CSRF protection because they receive machine-to-machine requests, not browser sessions. This is fully compensated by the cryptographic signature verification described above.

3.8 Data Protection and Secrets Management

All application credentials, API keys, and service tokens are stored as environment variables — never in source code or configuration files committed to version control. A template file documents required variables without exposing values.

Field-level encryption is applied to particularly sensitive data fields using Fernet symmetric encryption (via django-encrypted-model-fields). Currently this covers anonymous tip contact information. Encryption of additional sensitive fields, including notification service API tokens stored in the database, is a documented item on our security improvement roadmap.

All data transmitted between users and the platform — through the web application, mobile application, or API — is encrypted using TLS. Unencrypted HTTP connections are not permitted in production.

3.9 Biometric Data and AI Processing

🔒 On-Infrastructure Processing — No Third-Party AI Transmission

All biometric data processed by Shepard's Beacon — including facial recognition analysis and voice biometric processing — runs on infrastructure controlled by Shepard's Beacon within GCP. We do not transmit photographs, voice recordings, or derived biometric templates to external AI providers such as OpenAI, Google's public AI APIs, AWS Rekognition, or any similar third-party service.

For cross-border search coordination, biometric data is converted to anonymized hashed vectors and bucketed descriptors before any cross-region operation. The original biometric data of any individual does not cross national borders within our federated architecture.

AI-generated outputs — including facial comparison scores, voice biometric likelihood ratios, and geographic clustering results — are investigative aids only. They are visible exclusively to users with appropriate role-level access and require independent human review before any action is taken.

3.10 Background Task Security

Long-running operations — including AI analysis jobs, SMS delivery, and notification processing — are handled through an asynchronous task queue (Celery with Redis). Security measures applied to background tasks include:

• Tasks pass database primary keys through the message queue, not raw sensitive objects or personal data

• All tasks include retry logic with backoff, preventing runaway error loops

• Role-filtered task outputs: daily case summary notifications are restricted to administrative and law enforcement roles only

• Token maintenance tasks run on a daily schedule to expire and clean up stale authentication tokens

• The Redis message broker is deployed within the private VPC and is not accessible from the public internet

4. Audit Logging and Tamper-Evident Records

Shepard's Beacon maintains a comprehensive audit log of all meaningful actions taken on the platform. The audit system is designed to be tamper-evident: records cannot be modified or deleted after creation, and any attempt to alter historical records can be detected.

4.1 What Is Logged

Every significant action on the platform generates an audit record, including:

• Case creation, modification, and deletion

• Access to sensitive case data, person records, and location information

• Tip submission and review actions

• Export operations

• Access-denied events (failed permission checks)

• User account changes and role assignments

Each audit record captures the identity and role of the acting user, the IP address and user agent of the session, the specific record affected, and a timestamp. View events are deduplicated: repeated views of the same record within a 5-minute window by the same user are consolidated into a single record with a view count, rather than generating redundant entries.

4.2 Tamper-Evident Hash Chain

Audit log records are linked using a SHA-256 hash chain. Each record includes a hash derived from its own content and the hash of the preceding record. This means that modifying any historical record would break the chain and be detectable by any integrity verification check. Audit records cannot be updated or deleted through normal application operations.

4.3 Behavioral Flags

The audit system applies automated flags to certain records that may warrant review:

• Sensitive flag: Applied to records involving personally identifiable information or health-adjacent data

• Off-hours flag: Applied to sensitive data access occurring outside defined business hours, as a potential insider threat indicator

• Case assignment mismatch: Flags access to cases where the acting user is not assigned as a case participant

4.4 Misuse Detection

A dedicated misuse detection service monitors audit log patterns for the following behaviors, each of which generates a tracked misuse event for security review:

• Excessive export: More than 5 export operations per hour by a single user

• Off-hours sensitive access: 3 or more sensitive record accesses within a 30-minute window outside business hours

• Excessive access-denied events: 10 or more permission failures per hour, suggesting attempted privilege escalation or unauthorized access

• Bulk queries: 50 or more VIEW events per hour by a single user

Misuse events are categorized by type (Unauthorized Access, Excessive Export, Off-Hours Access, Bulk Query, Role Escalation, Policy Violation, Suspicious Pattern) and tracked through a resolution workflow by Security Administrators.

5. Multi-Region Data Residency

Shepard's Beacon is architected to keep case data within the country where it originates. A region context middleware assigns every request to a specific geographic region, and database connections route accordingly. Supported regions are the United States, Canada, Mexico, and the Bahamas.

Administrative roles (Super Administrator, Administrator, Security Administrator) have federated access across all regions for platform governance purposes. All other roles are locked to their home region and cannot access data from other regions.

Cross-region matching operations — used to identify whether a missing person case in one country may match a report in another — use only anonymized hashed representations. No personally identifiable information or raw biometric data is transmitted across regional boundaries.

This architecture supports applicable data protection laws in each operating jurisdiction, including the Virginia Consumer Data Protection Act (US), PIPEDA (Canada), LFPDPPP (Mexico), and the Data Protection Act 2003 (Bahamas).

6. Communications Security

Shepard's Beacon uses Twilio for SMS alerts, voice notifications, and one-time passcode (OTP) delivery. The following controls apply to all platform communications:

• All Twilio API credentials are stored as environment variables and never in application code

• SMS delivery is registered under A2P 10DLC (Application-to-Person, 10-Digit Long Code) carrier registration, complying with anti-spam and anti-fraud requirements

• OTP codes are single-use, time-limited, and invalidated immediately upon use or expiration

• SMS notification payloads are designed to minimize sensitive content — alerts direct users to the platform rather than transmitting case details in the message body

• Mobile API access requires a valid API key in the X-API-Key header in addition to standard authentication

7. Deployment and Build Pipeline

Shepard's Beacon uses Google Cloud Build as its continuous deployment pipeline. All code changes go through an automated build and validation process before reaching the production environment. Deployments are:

• Triggered only from authorized code repositories and controlled branches

• Logged with full build provenance, identifying what was deployed, when, and by whom

• Validated against automated tests before any production deployment proceeds

• Reversible: the platform supports rollback to a prior known-good build if a deployment introduces unexpected behavior

Production, staging, and development environments are fully isolated. Production data is never used in non-production environments. All secrets are environment-specific and cannot be shared across environments.

8. Incident Response

In the event of a confirmed or suspected security incident, Shepard's Beacon follows a structured response process:

• Detection: Automated monitoring and audit log alerts identify anomalous activity

• Containment: Affected accounts or services are isolated to limit the scope of impact

• Investigation: Audit records, platform logs, and GCP monitoring data are reviewed to determine the nature and extent of the incident

• Remediation: The root cause is addressed and affected systems are verified before full service is restored

• Notification: Affected users and applicable regulatory authorities are notified within legally required timeframes

• Post-Incident Review: A structured review identifies lessons learned and changes to prevent recurrence

Security concerns and suspected incidents may be reported to: security@shepardsbeacon.app

9. Responsible Disclosure

Shepard's Beacon welcomes reports from security researchers, platform users, and partner organizations who identify potential vulnerabilities. We commit to:

• Acknowledging all security reports within 5 business days

• Investigating credible reports in good faith

• Communicating findings and remediation timelines to reporters

• Not pursuing legal action against researchers who act in good faith and follow responsible disclosure practices

Please report security concerns to security@shepardsbeacon.app before any public disclosure. We request a 90-day window to investigate and remediate before publication.

10. Ongoing Security Improvement

Security is a continuous practice, not a one-time configuration. Shepard's Beacon maintains a documented security improvement roadmap. Current items under active development include:

• Enabling MFA enforcement for Super Administrator, Administrator, Law Enforcement, and Security Administrator roles

• Encrypting API tokens and service credentials stored in the database using field-level encryption

• Tightening Content Security Policy to nonce-based directives, eliminating 'unsafe-inline'

• Strengthening minimum password length requirements

• Auditing template rendering for cross-site scripting exposure points

• Adding structured JSON logging for production security information and event management (SIEM) integration

✓ Our Security Commitment

We publish our security posture honestly, including what we have built, what GCP provides, and what we are still improving.

The trust placed in us by families of the missing, law enforcement partners, and community volunteers is not taken lightly. We will continue to earn that trust through transparency, disciplined security practice, and continuous improvement.

Contact

Shepard's Collective Ministries — Security Team

Email: security@shepardsbeacon.app

General inquiries: privacy@shepardsbeacon.app

Web: www.shepardsbeacon.app

This document reflects the Shepard's Beacon security posture as of April 3, 2026 and is reviewed periodically as the platform evolves.

Shepard's Collective Ministries · Serving Communities Through Faith, Technology, and Action