TrailBlaze Adventures – Domain 3 Security Architecture and Engineering Case

Scenario — TrailBlaze Platform Redesign

TrailBlaze Adventures is redesigning its core digital platform to support global growth, real-time safety tracking, and stronger protection of customer and operational data.

The company is planning a major architecture upgrade that combines:

Multi-region cloud services for booking, customer profiles, and expedition management
Mobile apps and field devices used by guides in remote environments
GPS and safety systems that support real-time location and emergency coordination
Third-party integrations for payments, insurance, local partners, and messaging

Engineering pressure

New features must ship quickly to support business expansion.
Systems need to remain available during high travel seasons and emergencies.
Remote operations require resilient offline and sync-safe designs.
Sensitive data must remain protected across devices, apps, and cloud systems.

Architecture concerns

Different teams make inconsistent security design decisions.
Cryptographic key handling is not standardized across services.
Hardware trust, secure boot, and device integrity are not fully defined.
Resilience and failover requirements vary by system and region.

Management request: “Design a secure architecture for TrailBlaze that protects critical systems, supports resilient operations, and builds security into the platform from the start.”

Student assignment

Investigate the case

Analyze the TrailBlaze scenario and identify key challenges related to security architecture and engineering.

Which systems are most critical to protect and keep available?
Where are trust boundaries weak or unclear?
Which components need stronger encryption or key protection?
How should resilience and fault tolerance be designed?
Which design choices reduce long-term attack surface?

Identify Domain 3 challenges

Group findings under secure design, trusted components, cryptography, platform security, isolation, resilience, and hardware or firmware trust.

Link challenges to Domain 3 concepts

Connect each identified challenge to CISSP Domain 3 concepts and explain why that concept matters in the TrailBlaze architecture.

Deliverable: A structured list of at least 10 security architecture and engineering challenges, each linked to one or more Domain 3 concepts.

Domain 3 challenges to investigate

Secure Design

No consistent architecture principles are enforced across teams.
Security is sometimes added late instead of being designed in.
System boundaries and trust relationships are not always explicit.

Cryptography & Key Protection

Encryption exists, but key management differs by platform and provider.
Some field systems may store secrets insecurely on mobile devices.
Certificate handling and rotation are not uniformly automated.

Resilience & Availability

Emergency support services require high availability across regions.
Failover and redundancy expectations differ between business units.
Offline guides need systems that remain safe during sync failures or outages.

Trusted Components

Device integrity checks are incomplete for GPS and field equipment.
Secure boot, firmware trust, and root-of-trust controls are not standardized.
Shared infrastructure increases risk if isolation is weak.

Isolation & Segmentation

Customer systems, admin functions, and partner services need clearer separation.
Test and production environments may be too closely connected.
Compromise in one component could spread to high-value systems.

Modern Platforms

Cloud-native services, mobile apps, and IoT devices create varied attack surfaces.
Container and API security must align with architecture decisions.
Engineering teams need reusable secure patterns for future growth.

Link challenges to Domain 3 concepts

Students must connect each identified challenge to CISSP Domain 3 concepts.

Challenge	Domain 3 Concept	Explanation
Teams make inconsistent design decisions	Secure Design Principles	Shared design principles such as least privilege, defense in depth, and fail secure reduce architectural weaknesses.
Critical safety systems must remain available	Resilience / Fault Tolerance / Redundancy	High-availability systems need resilient design, backup capacity, and recovery planning.
Mobile and field devices may store secrets insecurely	Secure Storage / Trusted Platform Controls	Secrets should be protected using secure hardware features, protected keystores, or strong platform controls.
Certificates and keys are handled inconsistently	Cryptography / PKI / Key Management	Strong encryption depends on secure lifecycle management for keys, certificates, and trust chains.
Customer and admin systems are not clearly separated	Isolation / Security Boundaries	Architectural separation reduces the chance that compromise of one component affects another.
Field equipment integrity is uncertain	Secure Boot / Root of Trust / Trusted Computing	Trusted startup and verified firmware reduce tampering and unauthorized code execution.
Cloud and partner services expand the attack surface	Attack Surface Management / Architecture Patterns	Reusable secure patterns help control complexity as the system grows.
Offline operations may fail during sync or outage	Fail Secure / Availability Engineering	Systems should preserve security and essential operations even when communication is disrupted.
Shared infrastructure creates cross-system risk	Virtualization / Container Isolation	Isolation in modern platforms is essential to prevent compromise between workloads.
New features ship without architecture review	Security Engineering Governance	Secure engineering processes ensure architecture risk is reviewed before implementation decisions become permanent.

Learning outcomes

Outcome 1

Design securely

Apply secure design principles to complex business platforms with cloud, mobile, and field systems.

Outcome 2

Protect trust

Understand how trusted components, cryptography, and secure boot support system integrity.

Outcome 3

Build resilience

Evaluate redundancy, failover, and fault tolerance requirements for real-world operational environments.

Outcome 4

Control boundaries

Analyze how isolation and architectural boundaries reduce attack surface and limit compromise.

Instructor tip

Use this case in three phases:

Phase 1

Model

Students map the major systems, trust boundaries, and high-value components.

Phase 2

Evaluate

Students identify design weaknesses in trust, resilience, and key protection.

Phase 3

Redesign

Students propose a more secure architecture with clear controls and tradeoffs.