Security Testing Approaches

4.5.1 The Testing Pyramid

Security testing should follow a pyramid approach:

graph TD
    A[Unit Security Tests - Constant] --> B[Static Analysis SAST - Continuous]
    B --> C[Dynamic Testing DAST - More frequent]
    C --> D[Penetration Testing - Few comprehensive]
    
    style A fill:#90EE90
    style B fill:#87CEEB
    style C fill:#FFE4B5
    style D fill:#FFB6C1

4.5.2 Static Application Security Testing (SAST)

SAST analyzes source code without executing it. Think of it as spell-check for security.

What SAST Finds

• Buffer overflows
• SQL injection vulnerabilities
• Hardcoded passwords
• Resource leaks
• Cryptographic weaknesses
• Input validation issues

SAST Tools by Language

C/C++:

• Coverity
• PC-lint Plus
• PVS-Studio
• Clang Static Analyzer

Java:

• FindBugs/SpotBugs
• SonarQube
• Checkmarx
• Fortify

Python:

• Bandit
• PyLint with security plugins
• Semgrep

Multi-Language:

• Veracode
• Synopsys
• GitLab SAST

Implementing SAST Effectively

Integration Points

flowchart LR
    A[Developer Writes Code] --> B[IDE Plugin Scans]
    B --> C[Commit Hook Checks]
    C --> D[CI/CD Pipeline Scans]
    D --> E[Nightly Deep Scans]
    E --> F[Security Review]

Managing False Positives SAST tools often produce false positives. Manage them by:

• Tuning rules to your context
• Creating suppressions with justification
• Regular review of suppressed issues
• Tracking suppression metrics

4.5.3 Dynamic Application Security Testing (DAST)

DAST tests the running application, like a doctor examining a patient.

What DAST Finds

• Authentication bypasses
• Session management flaws
• Injection vulnerabilities in practice
• Configuration errors
• Encryption weaknesses

DAST Approaches

Black Box Testing

• No knowledge of internals
• Tests like an attacker would
• Finds real-world vulnerabilities

Gray Box Testing

• Some knowledge provided
• More efficient testing
• Better coverage

DAST Tools

• OWASP ZAP (free, open source)
• Burp Suite
• Acunetix
• AppScan

Creating DAST Test Cases

Focus on medical device specific scenarios:

Authentication Testing

Test: Emergency Override Access
1. Attempt normal login - verify required
2. Trigger emergency mode
3. Verify emergency access granted
4. Confirm audit log created
5. Test session termination

Data Protection Testing

Test: Patient Data Encryption
1. Monitor network traffic
2. Enter patient data
3. Verify encryption in transit
4. Check stored data encryption
5. Test for data leakage in logs

4.5.4 Fuzz Testing: Finding the Unexpected

Fuzzing sends malformed inputs to find crashes and vulnerabilities.

Why Fuzzing Matters for Medical Devices

Medical devices often:

• Parse complex data formats (DICOM, HL7)
• Handle sensor inputs
• Process network protocols
• Read configuration files

Each parsing point is a potential vulnerability.

Fuzzing Approaches

Mutation-Based Fuzzing

• Start with valid inputs
• Randomly modify them
• Monitor for crashes

Generation-Based Fuzzing

• Define input format
• Generate test cases
• More targeted approach

Fuzzing Tools

Network Protocol Fuzzing:

• Peach Fuzzer
• Boofuzz
• AFL++

File Format Fuzzing:

• AFL (American Fuzzy Lop)
• LibFuzzer
• Honggfuzz

Medical Device Fuzzing Example

# Example: Fuzzing HL7 message parser
def fuzz_hl7_parser():
    base_message = "MSH|^~\&|SENDING|SENDER|RECEIVING|RECEIVER|20231010120000||ADT^A01|MSG001|P|2.3"
    
    mutations = [
        # Length attacks
        base_message * 1000,
        base_message[:10],
        
        # Special characters
        base_message.replace("|", "||||"),
        base_message.replace("^", "\x00"),
        
        # Format violations
        "NOT_AN_HL7_MESSAGE",
        base_message.replace("MSH", "XXX"),
    ]
    
    for mutated in mutations:
        try:
            parse_hl7(mutated)
        except Exception as e:
            log_potential_vulnerability(e)

4.5.5 Penetration Testing: Real-World Attack Simulation

Penetration testing simulates real attacks against your device.

When to Conduct Penetration Testing

The JSP recommends:

• Before initial release
• After major changes
• Annually for high-risk devices
• When new threats emerge

Penetration Testing Scope

Network Testing

• External attack surface
• Internal network access
• Wireless interfaces
• Remote access paths

Physical Access Testing

• USB port attacks
• Debug interface access
• Hardware tampering
• Side-channel attacks

Application Testing

• Authentication bypass
• Privilege escalation
• Data extraction
• Firmware modification

Selecting Penetration Testers

Look for:

• Medical device experience
• Experience with embedded systems
• Clear methodology
• Actionable reporting

Ask about:

• Testing approach
• Safety considerations
• Coordination procedures
• Deliverables format

4.5.6 Security Test Planning

Test Plan Elements

Your security test plan should include:

Scope Definition

• What's being tested
• What's out of scope
• Risk-based prioritization

Test Cases

• Mapped to requirements
• Linked to threat model
• Covering all controls

Success Criteria

• No critical vulnerabilities
• All controls functioning
• Performance acceptable

Safety Considerations

• Test environment isolation
• Clinical safety preservation
• Rollback procedures

Test Automation Strategy