Hop And Haul Policies

Appearance

FedRAMP Development Roadmap ​

Document ID: PLCY-FED-004
Version: 1.0
Effective Date: December 30, 2025
Last Review: December 30, 2025
Owner: Hop And Haul Team

CONFIDENTIAL

This document is CONFIDENTIAL and for internal use only. Do not distribute outside the organization.

1. Purpose ​

This document provides a detailed development roadmap for achieving FedRAMP Moderate authorization and implementing the security controls required for "Federal Ready" status. It builds the system in three phases: Secure Core, Safety Operations, and Federal Hardening.

2. Roadmap Overview ​

PhaseFocusKey Deliverables
Phase 1Secure CoreDatabase isolation, authentication hardening, verification
Phase 2Safety OperationsSOS features, telematics security, admin controls
Phase 3Federal HardeningFIPS compliance, PIV/CAC, continuous monitoring

3. Phase 1: The Secure Core ​

Goal: A working rideshare platform where data leakage is mathematically impossible through architectural controls.

3.1 Database & Isolation Architecture ​

Current State ​

  • PostgreSQL RDS with basic access controls
  • Tenant isolation through application logic

Target State ​

  • Row Level Security (RLS) enforced at database level
  • Tenant ID on every table with RLS policies
  • Separate schema/encryption keys for Mission Mode fleets

Implementation Tasks ​

TaskDescriptionPriority
RLS Policy ImplementationDefine tenant_id on all tables, write RLS policies that block cross-tenant queriesCritical
Middleware EnforcementApplication layer validates tenant ID on all requestsCritical
Query AuditingLog all database queries with tenant contextHigh
Schema Isolation (Mission Mode)Separate schemas for high-security tenantsMedium
Key SeparationPer-tenant encryption keys for sensitive dataMedium

Technical Specifications ​

sql
-- Example RLS Policy
ALTER TABLE rides ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON rides
    USING (org_id = current_setting('app.current_org_id')::uuid);

-- Middleware sets tenant context
SET app.current_org_id = 'org_uuid_here';

Success Criteria ​

  • [ ] RLS policies on all tables with tenant data
  • [ ] No query can return data from another tenant
  • [ ] Automated cross-tenant access tests in CI/CD
  • [ ] Audit logs capture all data access with tenant context

3.2 Authentication System ​

Current State ​

  • SSO integration with session management
  • MFA for admin roles

Target State ​

  • "Short Access / Long Refresh" token pattern
  • Step-up authentication for critical actions
  • Device binding for mobile sessions

Implementation Tasks ​

TaskDescriptionPriority
Token Lifecycle15-minute access tokens, secure refresh rotationCritical
Step-Up AuthBiometric/PIN re-verification for sensitive actionsCritical
Device BindingSession tied to device fingerprintHigh
Secure StorageiOS Keychain / Android Keystore for tokensHigh
Session MonitoringReal-time session tracking and revocationMedium

Token Specifications ​

Token TypeLifetimeStorageRevocation
Access Token15 minutesMemoryAutomatic expiry
Refresh Token7 daysKeychain/KeystoreRotation on use
Ride TokenRide + 15 minMemoryAuto-expire

Step-Up Auth Triggers ​

ActionAuthentication Required
/ride/acceptBiometric or PIN
/ride/startBiometric or PIN
/sosNone (emergency)
/admin/exportMFA
/admin/user/modifyMFA

Success Criteria ​

  • [ ] Access tokens expire in 15 minutes
  • [ ] Refresh tokens rotate on each use
  • [ ] Step-up auth required for critical actions
  • [ ] Session bound to specific device

3.3 The "Happy Path" with Verification ​

Current State ​

  • Matching logic with location fuzzification
  • Basic ride verification

Target State ​

  • Mandatory identity verification handshake
  • PIN/QR exchange before ride start
  • Mismatch reporting with immediate response

Implementation Tasks ​

TaskDescriptionPriority
QR/PIN HandshakeGenerate unique code for each ride, verify before startCritical
Mismatch FlowOne-tap report blocks ride, alerts safety opsCritical
Photo VerificationDisplay driver photo to rider for visual confirmationHigh
Coarse LocationShow "X mins away" not map dot until commitmentHigh
Anti-TriangulationNew random offset per offerImplemented

Verification Flow ​

1. Ride Accepted → Generate unique 6-digit PIN + QR
2. Rider shows PIN/QR to Driver
3. Driver scans/enters code
4. API validates: /ride/start fails without valid code
5. Mismatch? → One-tap "Report Mismatch" → Ride blocked

Success Criteria ​

  • [ ] Ride cannot start without PIN/QR verification
  • [ ] Mismatch report blocks ride immediately
  • [ ] Location hidden until acceptance
  • [ ] Device binding prevents phone switching

4. Phase 2: Safety Operations & Abuse Prevention ​

Goal: Managing behavioral risks and the "human" element of the system.

4.1 The "Silent" Safety Suite ​

SOS Button Implementation ​

ComponentFunctionality
UI Trigger"Fake Cancel" button appears to end ride
BackendTriggers safety ops alert silently
Data CaptureSnapshots last 5 mins GPS + metadata
StorageImmutable Incident Bucket (S3 Object Lock)
AlertPagerDuty/Twilio to Fleet Safety Manager

Deviation Monitoring ​

TriggerThresholdResponse
Route deviation>5 miles from plannedCheck-in prompt
Time deviation>10 mins unexpectedCheck-in prompt
No response2 minutesEscalate to supervisor
Still no response5 minutesEscalate to emergency contacts
Emergency10 minutes no responseLaw enforcement notification

Duress Code ​

FeatureImplementation
Code TypeSpecific PIN pattern
TriggerEnter duress PIN instead of normal PIN
ResponseSilent alert to safety team
UINormal ride appears to continue

Implementation Tasks ​

TaskDescriptionPriority
SOS Backend WorkerBackground service for SOS processingCritical
GPS SnapshotCapture and store last 5 mins on triggerCritical
Immutable StorageS3 Object Lock for incident dataCritical
Deviation GeofencingReal-time route comparisonHigh
Check-In PromptsIn-app safety check-insHigh
Duress CodeSilent alerting mechanismHigh
Escalation TreeAutomated escalation workflowHigh

Success Criteria ​

  • [ ] SOS triggers within 2 seconds
  • [ ] GPS data captured and immutably stored
  • [ ] Safety ops alerted within 30 seconds
  • [ ] Deviation alerts for >5 mile/min variance
  • [ ] Escalation to authorities within 15 mins if no response

4.2 Telematics Integration (Samsara) ​

Security Requirements ​

RequirementImplementation
Key StorageAWS Secrets Manager (never in code/DB)
Key ScopeRead-only, specific vehicle tags only
Envelope EncryptionPer-tenant key wrapping
Rate LimitingPer-tenant API limits
Anomaly DetectionUsage spike alerting
Kill SwitchAuto-revoke on anomaly

Implementation Tasks ​

TaskDescriptionPriority
Secrets Manager IntegrationMove all API keys to Secrets ManagerCritical
Envelope EncryptionImplement per-tenant key wrappingHigh
Rate LimitingPer-tenant Samsara API limitsHigh
Anomaly DetectionMonitor for usage spikesHigh
Auto-RevocationKill switch on detected anomalyHigh
Key RotationAutomated quarterly rotationMedium

Success Criteria ​

  • [ ] No API keys in code, config files, or database
  • [ ] Per-tenant encryption with separate keys
  • [ ] Rate limiting prevents abuse
  • [ ] Anomaly detection triggers within 1 minute
  • [ ] Kill switch revokes keys within 30 seconds

4.3 Admin & Support Portal ​

Just-In-Time (JIT) Access ​

PrincipleImplementation
No BrowsingAdmins cannot search without justification
Ticket RequiredAccess requires valid ticket ID
Time-BoxedAccess expires after defined period
LoggedAll access logged with justification

Implementation Tasks ​

TaskDescriptionPriority
JIT Access SystemTicket ID + time-box required for accessCritical
Break-Glass AlertsImmediate alert on "view all" accessCritical
Default RedactionLocation/PII masked in admin viewsHigh
Audit LoggingComprehensive admin action loggingImplemented
Search RestrictionsRequire specific criteria, no SELECT *High

Admin View Redaction ​

Data TypeDefault ViewBreak-Glass View
LocationRegion onlyFull GPS (logged)
PhoneMasked (--1234)Full (logged)
NameFirst + Last InitialFull (logged)
Trip DetailsSummaryFull (logged)

Success Criteria ​

  • [ ] No admin can access data without ticket ID
  • [ ] Access automatically expires after time limit
  • [ ] Break-glass usage triggers immediate alert
  • [ ] All admin actions logged with full context

5. Phase 3: Federal Hardening ​

Goal: NIST 800-53 / FedRAMP Moderate readiness with "High Consequence" protections.

5.1 Continuous Monitoring & Logging ​

SIEM Integration ​

ComponentImplementation
Log AggregationCloudWatch → SIEM
Correlation RulesCross-system event correlation
Threat DetectionML-based anomaly detection
Alert AutomationPagerDuty integration

Alert Configuration ​

Alert TypeTriggerResponse
Root/JailbreakDevice check failureBlock access
Impossible TravelLocation teleportationForce re-auth
Admin Break-GlassAny usageImmediate review
API Key SpikeUsage >200% baselineInvestigation
Cross-Tenant AttemptAny occurrenceBlock + investigate

Implementation Tasks ​

TaskDescriptionPriority
SIEM IntegrationCloudWatch to security platformHigh
Correlation RulesDefine detection rulesHigh
Automated ResponseBlock/alert on detectionHigh
DashboardSecurity metrics visualizationMedium
ReportingAutomated compliance reportsMedium

5.2 Data Lifecycle Automation ​

Lifecycle Policies ​

Data StateRetentionStorageAction
Live GPS<24 hoursHot DBAuto-delete
Billing SummaryPer policyCold StorageNo GPS
Incident Data7 yearsImmutable S3Legal hold capable
Audit Logs24 monthsEncrypted S3Lifecycle transition

Automated Jobs ​

JobScheduleFunction
GPS PurgeNightlyDelete GPS breadcrumbs >48 hours
Billing ArchiveWeeklyMove summaries to cold storage
Log TransitionWeeklyMove logs to appropriate tier
Integrity CheckDailyVerify audit log integrity
Key RotationQuarterlyRotate encryption keys

Implementation Tasks ​

TaskDescriptionPriority
GPS Auto-DeletionLambda to purge old GPS dataHigh
Billing ArchivalMove to cold storageMedium
Log LifecycleS3 lifecycle policiesMedium
Integrity VerificationChecksum validationHigh
Cryptographic ErasureKey destruction for expired dataHigh

5.3 "Mission Mode" Features ​

Mission Mode Capabilities ​

FeatureDescription
Allow-List MatchingDisable open matching, pre-approved drivers only
MDM RequirementDevice attestation required
No Voice AgentApp-only acceptance (no phone commands)
2-Person IntegrityAdmin overrides require dual approval
Enhanced AuditAdditional logging for all operations

Implementation Tasks ​

TaskDescriptionPriority
Mission Mode TogglePer-tenant/per-ride booleanHigh
Allow-List EnforcementPre-approved driver matchingHigh
MDM CheckDevice Attestation API integrationHigh
Voice DisableBlock voice agent for mission ridesMedium
Dual Control2-person approval workflowMedium

Mission Mode Activation ​

Tenant → Enable Mission Mode →
  • Matching restricted to allow-list
  • MDM check required for all devices
  • Voice agent disabled
  • Enhanced audit logging enabled
  • Admin actions require dual approval

5.4 FIPS and PIV/CAC Compliance ​

FIPS 140-2 Requirements ​

ComponentCurrentTarget
Encryption LibraryStandard OpenSSLFIPS-validated module
Key ManagementAWS KMSAWS KMS (FIPS endpoint)
TLSTLS 1.3TLS 1.3 (FIPS ciphers)
HashingSHA-256SHA-256 (FIPS module)

PIV/CAC Integration ​

CapabilityImplementation
Certificate AuthSupport for PIV certificates
Smart Card ReaderMobile and desktop support
OCSP ValidationCertificate revocation checking
Fallback AuthStandard MFA if PIV unavailable

Implementation Tasks ​

TaskDescriptionPriority
FIPS Module IntegrationReplace crypto with FIPS-validatedHigh
FIPS KMS EndpointUse AWS KMS FIPS endpointsHigh
PIV/CAC SupportImplement certificate authenticationMedium
Certificate ValidationOCSP/CRL integrationMedium

6. Documentation & Evidence Collection ​

6.1 Required Documentation ​

DocumentOwnerStatus
System Security Plan (SSP)SecurityIn Progress
Control Implementation SummarySecurityIn Progress
Risk AssessmentSecurityComplete
Contingency PlanOperationsComplete
Incident Response PlanSecurityComplete
Configuration Management PlanDevOpsComplete
Privacy Impact AssessmentLegalPlanned

6.2 Assessment Activities ​

ActivityTimingOwner
Internal Control TestingOngoingSecurity
Penetration TestAnnual3PAO
Tabletop ExercisesQuarterlySecurity
Readiness AssessmentPre-authorization3PAO
Full AssessmentAuthorization3PAO

6.3 Tabletop Exercise Scenarios ​

ScenarioFocusFrequency
Kidnapping/RansomSOS/IR flowAnnual
Data BreachNotification proceduresQuarterly
RansomwareRecovery proceduresQuarterly
Insider ThreatInvestigation proceduresAnnual
API CompromiseKey rotation proceduresQuarterly

7. Milestone Summary ​

Phase 1 Milestones ​

MilestoneDeliverable
M1.1RLS implemented on all tables
M1.2Token lifecycle (15-min access) implemented
M1.3Step-up authentication for critical actions
M1.4PIN/QR verification handshake
M1.5Device binding implemented

Phase 2 Milestones ​

MilestoneDeliverable
M2.1SOS backend with immutable storage
M2.2Deviation monitoring active
M2.3Samsara keys in Secrets Manager
M2.4JIT access for admin portal
M2.5Anomaly detection operational

Phase 3 Milestones ​

MilestoneDeliverable
M3.1SIEM integration complete
M3.2Data lifecycle automation
M3.3Mission Mode available
M3.4FIPS-validated crypto
M3.53PAO readiness assessment

8. Success Metrics ​

MetricTarget
Cross-tenant query attempts blocked100%
Step-up auth bypass attempts0
SOS response time<2 minutes
Deviation detection time<5 minutes
Admin break-glass alerts<1 minute
NIST control coverage>95%
FedRAMP assessment findings<5 medium

9. Related Documents ​

DocumentRelationship
PLCY-FED-001Federal compliance overview
PLCY-FED-003Risk mitigations
PLCY-FED-005Control mapping
PLCY-SEC-001Current security controls
PLCY-DRP-001Recovery procedures

10. Document Control ​

VersionDateAuthorChanges
1.0December 30, 2025Hop And Haul TeamInitial release

CONFIDENTIAL - Internal Use Only - Hop And Haul Policy Documentation

Hop And Haul Team - Do Not Distribute