Cyber Security test plan #87
Description
Relevant Standards and Frameworks
- ISO/IEC 27001 – Information Security Management
- ISO/IEC 27005 – Risk management (assets, threats, CIA)
- FAA NTAP – Risk-based evaluation of UTM services
- EASA AMC2 Article 15(1)(b) – Protection against intentional unauthorized electronic interaction (IUEI)
- GUTMA Secure & Resilient UTM Framework – Asset-based threat modeling
What These Standards Expect
- Documented threat modeling
- Identification of primary and supporting assets
- Demonstrated controls for confidentiality, integrity, and availability (CIA)
- Evidence of testing, not just design intent
- Logs, reports, and traceability suitable for customers and authorities
Phased testing approach
Threat modeling
tools: Spreadsheet, Mermaid
Establishing a shared understanding of what we are protecting, what can go wrong, and which risks actually matter from a safety, operational, and customer perspective.
What needs to be done:
- Identify primary assets (services, data, decisions) provided by Flight Blender
- Identify supporting assets (APIs, databases, queues, external integrations)
- Define trust boundaries and external dependencies
- Identify credible threat scenarios (spoofing, tampering, DoS, abuse of privilege)
- Assess impact using Confidentiality, Integrity, Availability (CIA)
How:
- Walk through the system end-to-end using architecture diagrams
- Annotate data flows and entry points
- Capture threats in structured tables
- Keep the assessment qualitative and pragmatic
Outputs:
- Asset inventory (primary & supporting)
- High-level threat model
- Initial risk register (no mitigations yet)
Required output: Table formatted threat-risk-asset mapping
Static analysis
tools: Bandit, Github CodeQL, Trivy, Safety
- Catch known vulnerabilities early.
- We should implement a CVE checker in our gitlab pipelines to constantly check the dependencies for known issues.
- Make sure we automatically update security fixes in third party dependencies.
- Required output: CVE reports, automatic updates, dependency summaries
Control Verification
tools: postman, pytest
What:
- Verify authentication mechanisms
- Verify authorization and role separation
- Validate input handling and error behavior
- Confirm encryption and secure defaults
How:
- Exercise APIs with valid and invalid identities
- Attempt privilege escalation and role misuse
- Submit malformed or unexpected payloads
- Observe system behavior and logs
Adversarial & Misuse Testing
tools: pytest
Testing how the system behaves under intentional misuse, not just accidental errors.
What:
- Attempt data tampering and replay
- Test API misuse patterns
- Stress trust boundaries
- Exercise known threat scenarios from Phase 1
- Ensure flight, geofence, and operator data cannot be manipulated or leaked
- Ensure communications are always encrypted
- Ensure all payloads are strictly validated
- Block replay attempts
How:
- Manipulate payloads and headers
- Replay previously valid requests
- Chain small weaknesses together
- Focus on realistic attacker behavior
Resiliency
tools: k6, locust
Understanding system behavior under load, dependency failure, or partial outages.
What:
- Simulate high traffic scenarios
- Test dependency unavailability
- Observe degradation and recovery behavior
- Test queue saturation
- Idempotency and crash resistance
How:
- Gradually increase request volume
- Disable or delay external services
- Observe timeouts, retries, and fallbacks
- Ensure behavior always stays safe, no matter the load or failures.
Monitoring
What:
- Trigger known security events
- Verify logs and alerts
- Review incident response assumptions
- All attacks and failures should be detectable and traceable
How:
- Generate failed auth attempts
- Trigger abnormal usage patterns
- Verify correlation and traceability
- Logging evidence with correlation
- Alerts
- Incident response procedures exist.
Reporting
All phases must have an appropriate Report. Preferably all automated, so each new test round can be easily reported.