Geek Sync | Handling HIPAA Compliance with Your Data Access

download Geek Sync | Handling HIPAA Compliance with Your Data Access

of 29

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of Geek Sync | Handling HIPAA Compliance with Your Data Access

  • Handling HIPAA Compliance with Your Data Access

    November 15, 2017

  • About Me

    Infrastructure and security architect

    Database Administrator / Architect

    Former Incident Response team lead

    Certified Information Systems Auditor (CISA)

    SQL Server security columnist / blogger

    Editor for SQL Server benchmarks at Center for Internet Security

  • My Contact Information

    K. Brian Kelley


    Twitter: @kbriankelley

    Infrastructure/Security Blog:

    Personal Development Blog:

  • 5 Key Questions1. Who has access to my electronic PHI, and how do I audit the activity?

    2. How do I define a secure baseline and maintain it across my SQL Server environment?

    3. How can I implement repeatable processes to help maintain the security standards?

    4. How do I audit permissions, logins, and object and data changes on my SQL Server?

    5. What is the best way for me to ensure not only ongoing compliance with the HIPAA,

    HITECH, and Omnibus Rule regulations but also help maintain reasonable security

    across my SQL Server databases?


    Search Engine Keywords: IDERA HIPAA

  • Agenda

    Repeatable Processes (#3, #5)

    User Security (#4)

    Secure Configuration (#2, #5)

    Auditing Access (#1, #4)

  • Some of what SQL Server brings to bear to comply

    with HIPAA are found in features only available in

    Enterprise Edition. What you will need Enterprise

    Edition for:

    Extensible Key Management

    Transparent Data Encryption (TDE)

    What was added to Standard Edition, starting with

    SQL Server 2016 SP1:

    Always Encrypted

    Database-level (Fine-grained) Auditing

  • Repeatable Processes

  • Repeatable Processes

    Organizational Issue: Change Control

    Workflows must be consistent

    Documentation must be maintained

    Exceptions must be reported

    If theres no evidence for a control, its not a control.

  • What SQL Server Can Do

    User security to restrict access

    Data Definition Triggers:

    Enforce when changes can be made

    Enforce what types of changes can be made

    Schema Change History report

    SQL Server traces

    Extended Events

  • User Security

  • Login Security

    The Best Practice:

    1. All logins are via AD domain user accounts

    2. All logins are placed in security groups (preferably domain security groups)

    3. Security groups are granted login ability to SQL Server

  • If You Follow This Best Practice (and you should)

    Auditing and alerting must be present against Active Directory and OS

    Track changes to groups which provide access into the DB

    Track changes to groups which provide administrative rights to OS

    Track changes to users with privileged access:

    Through any applications

    Into SQL Server itself

  • Server Level Access

    Use Server-Level Roles for privileged access:


    User-defined role with granular security

    Dont use securityadmin

    Permissions to watch for:



  • Database Level Access

    Use roles for granting access

    Minimal permissions (principle of least privilege)

    Test permission scenarios (and have test results)

    Take into account how privileged accounts have implicit access

  • Secure Configuration SQL Server

  • Starting with a Secure Configuration

    Build server template with baseline security configuration

    Deploy server using template

    Scripted SQL Server install with minimal features

    After install scripts to harden SQL Server

  • Policy Based Management

    Can target groups of SQL Servers

    Most settings available to all components of SQL Server

    Enforce or detect change to configuration

    Can choose how to implement enforcement

  • Other Ways to Maintain

    Custom Scripts

    3rd Party Products

    Periodic Checks. Dont Rely on initial setup and


    ALWAYS audit security

    Server settings important for compliance requirements

  • Secure Communication

    Dont assume network is secure, even if its internal.

    Most larger organizations have large capture capability.

    Even if PHI data is encrypted in transit, other key information available.

    Secure communications with SQL Server:

    Server certificate SSL / TLS

    IPSEC (OS level)

  • Secure Configuration - Data

  • Encrypting Data at Rest

    Easy Button: Transparent Data Encryption

    OS Options:

    Encrypting File System (not recommended)


    Dont forget about backups

    TDE native backups encrypted automatically

    Encrypted backups new feature as of SQL Server 2014

    Every major 3rd party solution supports backup encryption

    Storage personnel may argue against it. Auditors will be on your side.

  • Encrypting Data in the DB

    TDE and OS file level encryption dont apply within SQL Server

    SQL Server has built-in encryption options if home grown

    Key management is a problem

    If SQL Server manages the keys then admins can see the data

    Always Encrypted is another option for home grown solutions

    Verify PHI data is encrypted

  • Speaking of Key Management

    With TDE, key management is crucial to recover the DB.

    Built-in encryption has key management challenges as well.

    Test your recovery scenarios extensively.

    Consider Extensible Key Management (EKM) solutions.

  • Auditing Access

  • Default Trace and Server Traces

    Default Trace runs by default

    Rolling capture of particular events

    Does capture schema change events

    Build Your Own Trace

    Use prior to Extended Events

    C2 audit mode

    Technically a trace

    Writes significant amounts of data

    Not recommended


  • Extended Events

    Can audit for anything you should need

    Can be made as lightweight as possible

    Does require legwork to get right

    Doesnt send information to OS event logs by default

    Easier solution: Audit objects

  • Audit Objects

    Two levels:


    Database (fine-grained)

    Track events at both levels

    Database level events:

    Can also grab SELECT queries (who is accessing the data)

    Dont assume all access is through the application(s)


    File system

    Application event log

    Security event log (recommended)

  • What We Looked at Today

    Repeatable Processes (#3, #5)

    User Security (#4)

    Secure Configuration (#2, #5)

    Auditing Access (#1, #4)

  • Further Print Resources:IDERA whitepaper:

    Microsoft SQL Server Compliance whitepaper:

    Experis Finance whitepaper:

    Securing SQL Server, Third Edition

    Denny Cherry (book published by Syngress)