Research and planning

Internal working document

This page is for internal planning only. It will not be included in the final response to BSI.

Analysis

What BSI is asking: Test C366/T228 ("Verify blocking of anomalous high-frequency request bursts") is mapped to SRS-CCD ("Intrusion Prevention and Malicious Traffic Detection"). BSI acknowledges that the waf_*.png screenshots and the TestRail CSV demonstrate parts 1-3 of the requirement (traffic inspection, automatic blocking, anomaly detection). However:

1. Parts 4 and 5 (alerting & audit logging; fail-secure behaviour) are not clearly covered by test T228.
2. Actual test results (HTTP 200 and 429 response codes, audit log entries) are not present in the documentation package.

What standard is at stake: EN 62304 § 5.5 requires that each software requirement be verified with documented evidence of actual results vs. expected results. MDR Annex II 6.1(b) requires the evidence artefacts themselves be in the technical file.

Underlying concern: BSI wants to see that all 5 parts of SRS-CCD have been tested, not just 3, and that the evidence shows the test was actually executed (not just that it was marked "Passed" in TestRail).

Terminology: "fail-secure", not "fail-safe"

The actual SRS-CCD requirement text for part 5 says: "Safety fail-secure behavior: Detection or blocking failures shall never result in bypassing security controls or exposing protected components."

"Fail-secure" and "fail-safe" are different concepts in cybersecurity:

• Fail-safe = defaults to a safe state (could mean allowing traffic if that keeps a clinical system running)
• Fail-secure = defaults to a locked-down state (denies access when the control fails)

Our requirement specifies fail-secure, which is a stronger security posture. The response to BSI must use the correct term from our own requirement.

Relevant QMS documents and sections

Document	Path	Relevance
SRS-CCD definition (all 5 parts)	apps/qms/src/components/SoftwareRequirements/software-requirements.json (line ~518)	Full requirement text including parts 4 and 5
Test C366/T228 in traceability matrix	apps/qms/src/components/TraceabilityMatrix/traceability-matrix.json (line ~1589)	Shows mapping SRS-CCD → C366/T228, status: Passed, reviewer: Gerardo Fernández, review: Approved
TestRail CSV — T228 row	apps/qms/src/components/TraceabilityMatrix/test_rail_verification_tests.csv (line 131)	Expected results: HTTP 200, HTTP 429/403, audit log. Required evidence: dashboard screenshot + rules screenshot. Tested: 2026-01-17
WAF screenshots (3 files)	apps/qms/static/img/gp-110/waf/aws-waf-dashboard-traffic-summary.png, aws-waf-web-acl-overview.png, aws-waf-acl-activity-rules.png	Configuration evidence (dashboard, rules) — addresses parts 1-3
OP.EXP.2 Security Configuration	apps/qms/docs/procedures/gp-110/op-marco-operacional/op-exp-explotacion/op-exp-2-configuracion-de-seguridad.mdx	Lists AWS WAF, AWS Shield, rate limiting, Wazuh SIEM as implemented. Does NOT describe fail-secure architecture or layered defence.
S3 evidence location	s3://legit-health-plus/software-tests/v1.1.0.0/02_software_verification/preproduction/test-plan-13/test_run_228/	Where actual test execution artefacts should be
Software Test Plan (R-TF-012-033)	apps/qms/docs/legit-health-plus-version-1-1-0-0/product-verification-and-validation/software/R-TF-012-033-Software-Test-Plan/index.mdx	Defines evidence pack structure (TestRail export + manual execution artifacts), S3 path convention, manifest.json with checksums
Software Test Report (R-TF-012-035)	apps/qms/docs/legit-health-plus-version-1-1-0-0/product-verification-and-validation/software/R-TF-012-035-Software-Test-Report/index.mdx	States "100% Passed. All test cases in the verification and commissioning suites reached 'Passed' status." T228 is included via TraceabilityMatrixTable component.
R-TF-030-001 Cyber Security Management Plan	apps/qms/docs/legit-health-plus-version-1-1-0-0/product-verification-and-validation/cybersecurity/R-TF-030-001-Cyber-Security-Management-Plan.mdx	Uses EMB3D methodology with "barriers" concept. Process document — does NOT contain WAF architecture details or defence-in-depth diagrams.
R-TF-030-003 Cyber Security Assessment Report	apps/qms/docs/legit-health-plus-version-1-1-0-0/product-verification-and-validation/cybersecurity/R-TF-030-003-Cyber-Security-Assessment-Report.mdx	Maps controls to IEC 62443-4-2; lists DDoS protection (CR 7.1) and continuous monitoring (CR 6.2). DEKRA CASA Tier 3 assessment passed. Does NOT explain what happens if WAF fails.

Gap analysis

What we have:

• SRS-CCD is clearly defined with all 5 parts in the software requirements
• Test C366/T228 exists, was reviewed and approved by Gerardo Fernández, and is marked Passed (2026-01-17)
• Expected results explicitly include HTTP 200, HTTP 429/403, and "the system records the anomaly event in the audit log with the enforcement action taken"
• 3 WAF screenshots showing dashboard, ACL overview, and rules
• OP.EXP.2 documents that AWS WAF, AWS Shield, rate limiting, and Wazuh SIEM are all implemented
• Evidence pack in S3 per the structure defined in R-TF-012-033 (TestRail export + execution artifacts + manifest.json with checksums)
• R-TF-030-003 passed DEKRA CASA Tier 3 security assessment

What's missing or unclear (BSI's concerns are valid):

Part	Requirement text	Evidence status
1. Traffic inspection	"Continuously monitor inbound API requests... for known attack signatures and anomalous request patterns"	Covered by existing WAF screenshots
2. Automatic blocking	"When malicious activity is detected, the system shall immediately block the source"	Covered by existing WAF screenshots
3. Anomaly detection	"Identify suspicious traffic patterns such as rapid request bursts"	Covered by existing WAF screenshots
4. Alerting & audit logging	"Record all intrusion-related events in the audit trail with timestamp, source IP, event classification, and enforcement action"	Audit log entries from test execution not provided in submission package. Expected results mention this but actual evidence is only in S3.
5. Fail-secure behaviour	"Detection or blocking failures shall never result in bypassing security controls or exposing protected components"	No explicit test evidence. Not directly testable by running T228 (which tests blocking, not WAF failure).

Root cause of the gap: Test T228 was designed to verify the rate-limiting/blocking capability (parts 1-3) and its expected results include audit log recording (part 4), but:

• The actual evidence (HTTP response codes, audit log entries) is in S3 and was not included in the submission package — this is a packaging problem, not an evidence problem.
• Part 5 (fail-secure) is an architectural property, not a functional test outcome. You cannot deliberately crash AWS WAF in a test to prove fail-secure — it requires verification by analysis of the infrastructure configuration per EN 62304 § 5.5.2.

Response strategy

Approach: Provide the actual test evidence (parts 1-4) + verify fail-secure by analysis (part 5)

1. Provide actual test results from S3: Extract from s3://legit-health-plus/software-tests/v1.1.0.0/02_software_verification/preproduction/test-plan-13/test_run_228/ the HTTP 200 and 429 response evidence and the audit log entries. Include these in the bookmarked PDF as supplementary evidence. This directly addresses BSI's concern about missing actual results per MDR Annex II 6.1(b).

2. Clarify part 4 (alerting & audit logging): Point to the test expected results (which DO include "the system records the anomaly event in the audit log with the enforcement action taken") and provide the actual audit log evidence from S3. Reference OP.EXP.2 for the Wazuh SIEM and DynamoDB audit table infrastructure.

3. Address part 5 (fail-secure behaviour) via architecture analysis: Per EN 62304 § 5.5.2, verification may be performed by analysis or review, not only by test execution. Fail-secure is an architectural property that is verified by confirming the infrastructure configuration:

   • AWS WAF default action: Confirm and document that our AWS WAF is configured with a default action of "Block" (fail-closed mode). If the WAF service cannot evaluate a request, the request is blocked — this IS fail-secure behaviour by design.
   • AWS Shield: Provides DDoS protection at the network layer independently of WAF. If WAF fails, Shield still protects.
   • API Gateway: Enforces authentication (JWT/IAM) independently of WAF. A WAF failure does not bypass API Gateway auth.
   • Document this as a verification-by-analysis record, either as an addendum to the test documentation or as a brief architecture analysis in the cybersecurity assessment (R-TF-030-003).
   Do NOT reference R-TF-030-001 or R-TF-030-003 for defence-in-depth

   These documents do not currently contain the defence-in-depth architecture details needed to support this argument. R-TF-030-001 is a risk management process document; R-TF-030-003 lists controls but does not explain layered redundancy or fail-secure behaviour. Either add the content first and then reference the updated document, or provide the architecture analysis directly in the response without citing these documents.

4. Key people to coordinate with: Gerardo Fernández (test executor and reviewer) for extracting S3 evidence and confirming AWS WAF configuration.

Confidence level: Medium-High. Parts 1-4 are strong — the evidence exists in S3, it just wasn't submitted. Part 5 (fail-secure) requires us to produce a brief architecture analysis that doesn't currently exist, but the underlying infrastructure does support the claim (AWS WAF default-Block, Shield, API Gateway auth). The risk is that BSI may want to see this documented in R-TF-030-003 rather than just explained in the response.