FSU Med Secure Apps Complete Guide to Secure Implementation

• Expanding PHI scope: Includes genetic information, mental health records, and substance abuse treatment data, which are not explicitly covered under HIPAA’s federal parity laws.
• Stricter consent requirements: Mandates explicit patient authorization for research or marketing uses of health data, even if permitted under HIPAA. FSU Med’s apps integrate Florida-specific consent workflows for state-regulated data categories.
• Breach thresholds: Florida law requires notification for breaches affecting any number of individuals, not just the HIPAA threshold of 500+. FSU Med’s incident response protocols include state-specific escalation paths to the Florida Department of Health (FDOH).

• Florida Board of Governors’ Data Security Standards: Aligns with Florida Administrative Code Rule 6C-14.003, requiring encryption for data in transit/rest, multi-factor authentication (MFA) for privileged access, and annual security training.
• FSU’s Data Classification Scheme: Categorizes data as Public, Internal, Confidential, or Restricted, with FSU Med apps handling Restricted (PHI) or Confidential (research-related EHI) tiers.
• Business Associate Agreements (BAAs): All third-party vendors processing PHI must sign FSU’s standardized BAA template, which includes Florida-specific clauses for FHIPA compliance.

Privacy Impact Assessment (PIA) Process for New App Features

Purpose and Scope
The PIA identifies:

Privacy risks inherent in new functionalities (e.g., data collection methods, sharing mechanisms, or third-party integrations) and ensures mitigations align with legal requirements and FSU Med’s risk appetite.

1. Initiation and Stakeholder Mapping
   The Product Owner or App Development Lead submits a PIA request to the FSU Med Privacy Office via the Compliance Tracking System (CTS). Key stakeholders include:
   • Privacy Officer: Leads the assessment and approves mitigations.
   • Security Architect: Evaluates technical safeguards (e.g., encryption, access controls).
   • Legal Counsel: Reviews FHIPA/HIPAA implications for Florida-specific data.
   • Data Stewards: Represent clinical/departmental perspectives on data usage.
   • Third-Party Vendors: Provide compliance documentation if the feature involves external systems.
2. Information Collection and Analysis
   The team documents:
   • Data Types: PHI elements collected (e.g., patient names, treatment notes, biometrics if applicable).
   • Data Flows: Sources (e.g., EHR integrations), destinations (e.g., analytics dashboards), and retention periods.
   • Legal Basis for Processing: Consents, treatment purposes, or research authorizations under HIPAA §164.501 and FHIPA §766.103(2).
   • Risk Identification: Potential vulnerabilities (e.g., unauthorized access, data leaks) using the NIST Risk Management Framework (RMF).
3. Mitigation Planning
   Controls are selected based on HIPAA Security Rule Safeguards and Florida’s Data Security Standards. Examples include:
   • Technical Safeguards: Tokenization for PHI in databases, FIPS 140-2 validated encryption for data at rest.
   • Administrative Safeguards: Role-based access reviews every 90 days, Florida-specific breach response drills.
   • Physical Safeguards: Biometric authentication for on-premise app servers in Florida State University’s Health Sciences Center.
4. Documentation and Approval
   The PIA report includes:
   • A risk register with residual risks and acceptance criteria.
   • Compliance mapping to HIPAA/FHIPA sections and FSU policies.
   • Training requirements for app users (e.g., Florida-specific consent procedures).
   Approval is granted by the FSU Med Privacy Committee and FSU’s Chief Information Security Officer (CISO).
5. Post-Implementation Review
   A 90-day follow-up audit verifies mitigations via:
   • Automated logs (e.g., failed login attempts, data access patterns).
   • User surveys to assess adherence to Florida-specific consent workflows.
   • Penetration test reports for new features (conducted by FSU’s Cybersecurity Lab or third-party assessors).

Regulatory alignment (HIPAA/FHIPA sections addressed),

Data lifecycle stage (e.g., collection, sharing),

Vendor involvement (if applicable),

Retention schedule (PIAs are archived for 7 years post-app retirement).

Data Lifecycle Governance with Security Controls

Data Lifecycle Flowchart (Plaintext for HTML Conversion)

┌───────────────────────────────────────────────────────────────────────────────┐
│ DATA LIFECYCLE OVERVIEW │
├─────────────────┬─────────────────┬─────────────────┬─────────────────────────┤
│ COLLECTION │ STORAGE │ SHARING

User Authentication and Identity Verification Methods in FSU Med Secure Apps

Comparison of Authentication Methods: Traditional vs. Modern Approaches

Traditional Login Methods (Username/Password)

Modern Authentication Alternatives
FSU Med integrates the following to address limitations of traditional methods:

- Biometrics (Fingerprint, Facial Recognition, Iris Scan)

- Hardware Tokens (FIDO2, YubiKey, Smart Cards)

- Risk-Based Authentication (RBA)

Alignment with NIST Digital Identity Guidelines (SP 800-63)

NIST SP 800-63 emphasizes:
1. Memorized Secret Verifiers: Passwords must meet complexity requirements (minimum 8 characters, including uppercase, lowercase, numbers, and symbols) and be hashed with bcrypt, Argon2, or PBKDF2.
2. Authenticator Assurance Levels (AAL1–AAL3): FSU Med assigns AAL2 (cryptographic protection) or AAL3 (multi-factor with cryptographic binding) for high-risk actions.
3. Phishing-Resistant Credentials: Hardware tokens (FIDO2) and biometrics (PIN-protected) are prioritized for privileged accounts.
4. Session Management: Enforces short-lived tokens (e.g., OAuth 2.0 with 15-minute expiration) and invalidates sessions after inactivity.
5. Credential Management: Supports passwordless flows (e.g., WebAuthn) and enforces periodic credential rotation for service accounts.

Multi-Factor Authentication Workflow for High-Risk Actions

1. Initial Access

2. MFA Prompt

3. Fallback Mechanisms

4. Session Validation

Mitigations for Common Identity System Vulnerabilities

Vulnerability: Credential Stuffing and Brute-Force Attacks

Vulnerability: SIM Swapping and Mobile OTP Interception

Vulnerability: Session Hijacking and Token Theft

Vulnerability: Insider Threats (Malicious or Negligent Users)

Secure App Development: Coding Standards and Threat Modeling in FSU Med Secure Apps

Secure Coding Practices and OWASP Top 10 Mitigations

- Input Validation and Sanitization
All user inputs (e.g., patient data, API requests) are validated against expected formats (e.g., regex for email, numeric ranges for ages) and sanitized to prevent injection attacks (SQL, command, XSS). Libraries like OWASP ESAPI and DOMPurify are used for sanitization, with strict whitelisting for allowed characters.

- Secure API Design
APIs adhere to RESTful principles with HTTPS enforcement, rate limiting, and JWT/OAuth 2.0 for authentication. Sensitive endpoints (e.g., patient records) require multi-factor authentication (MFA) and role-based access control (RBAC). API responses are paginated and sanitized to avoid information disclosure.

- Dependency Management
Third-party libraries are vetted using tools like OWASP Dependency-Check and Snyk, with automated scans in CI/CD pipelines. Critical dependencies (e.g., cryptographic libraries) are pinned to specific versions to avoid supply-chain attacks. Containerization (Docker) and immutable infrastructure reduce attack surfaces.

- Secure Error Handling
Errors expose minimal details (e.g., generic messages like "An error occurred") to prevent stack trace leakage. Logs are encrypted and stored separately from application data, with log rotation to limit exposure.

- Memory and Resource Management
Buffer overflows and denial-of-service (DoS) risks are mitigated via safe memory handling (e.g., bounds checking in C/C++ modules) and resource limits (e.g., connection pooling, request timeouts).

OWASP Top 10 Mitigations in FSU Med Secure Apps

Injection: Use prepared statements (SQL) and parameterized queries; avoid dynamic code execution.

Broken Authentication: Enforce password policies (minimum 12 chars, complexity), MFA, and session timeouts.

Sensitive Data Exposure: Encrypt data at rest (AES-256) and in transit (TLS 1.3); use HIPAA-compliant key management.

XML External Entities (XXE): Disable XML parsing or use safe parsers (e.g., `stax` in Java).

Broken Access Control: Implement attribute-based access control (ABAC) and regular access reviews.

Threat Modeling for Telehealth Video Calls Using STRIDE Methodology

STRIDE Threat Modeling Framework

Spoofing: Fake identities (e.g., impersonating a doctor).

Tampering: Altering call data (e.g., modifying medical notes).

Repudiation: Denying actions (e.g., patient claiming not to have consented).

Information Disclosure: Unauthorized access to call transcripts.

Denial of Service (DoS): Disrupting calls via bandwidth attacks.

Elevation of Privilege: Escalating access (e.g., patient accessing admin functions).

Secure Session Management Implementation

// Secure Session Configuration (Spring Boot)
@Configuration
public class SecurityConfig {
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.csrf(csrf -> csrf.disable()) // Use CSRF tokens for stateful apps; disable if using JWT
.sessionManagement(session -> session
.sessionCreationPolicy(SessionCreationPolicy.STATELESS) // No server-side sessions
.invalidSessionUrl("/login?error=invalid_session")
)
.headers(headers -> headers
.frameOptions(FrameOptionsConfig.DENY) // Prevent clickjacking
.contentSecurityPolicy("default-src 'self'") // CSP to mitigate XSS
.httpStrictTransportSecurity(hsts -> hsts
.includeSubDomains(true)
.maxAgeInSeconds(31536000) // 1 year
)
)
.and()
.addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class);

return http.build();
}

@Bean
public JwtAuthenticationFilter jwtAuthenticationFilter() {
return new JwtAuthenticationFilter();
}
}

// JWT Generation with Secure Headers
public String generateToken(UserDetails userDetails) {
Date now = new Date();
Date expiryDate = new Date(now.getTime() + 86400000); // 24h expiry

return Jwts.builder()
.setSubject(userDetails.getUsername())
.setIssuedAt(now)
.setExpiration(expiryDate)
.signWith(SignatureAlgorithm.HS512, secretKey) // Use RSA for production
.compact();
}

// Secure Cookie Attributes (Frontend Example)
document.cookie = `token=${jwtToken}; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=${expirySeconds}`;

Key Security Features: