Download to read offline
Uploaded byIDERA Software
Geek Sync | Handling HIPAA Compliance with Your Data Access
The document discusses how to ensure compliance with HIPAA regulations when handling electronic protected health information (ePHI) stored in SQL Server databases. It addresses five key questions around auditing access to ePHI, defining a secure SQL Server configuration baseline, implementing repeatable security processes, auditing permissions and changes in SQL Server, and maintaining ongoing compliance. The presenter provides recommendations for secure configurations, including role-based access control, encryption of data at rest and in transit, and auditing access through features like extended events and audit objects. Maintaining repeatable processes for security and change management is emphasized as important for compliance.
Geek Sync | Handling HIPAA Compliance with Your Data Access
- 1. Handling HIPAA Compliance with YourData Access November 15, 2017
- 2. About Me • Infrastructureand 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
- 3. My Contact Information K.Brian Kelley Email: kbriankelley@acm.org Twitter: @kbriankelley Infrastructure/Security Blog: http://truthsolutions.wordpress.com Personal Development Blog: http://gkdba.wordpress.com
- 4. 5 Key Questions 1.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? Source: https://www.idera.com/resourcecentral/whitepapers/security-and-compliance-solutions-for-hipaa Search Engine Keywords: IDERA HIPAA
- 5. Agenda • Repeatable Processes(#3, #5) • User Security (#4) • Secure Configuration (#2, #5) • Auditing Access (#1, #4)
- 6. Some of whatSQL 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
- 7.
- 8. Repeatable Processes • OrganizationalIssue: Change Control • Workflows must be consistent • Documentation must be maintained • Exceptions must be reported “If there’s no evidence for a control, it’s not a control.”
- 9. What SQL ServerCan 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
- 10.
- 11. Login Security The BestPractice: 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
- 12. If You FollowThis 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
- 13. Server Level Access •Use Server-Level Roles for privileged access: • sysadmin • User-defined role with granular security • Don’t use securityadmin • Permissions to watch for: • CONTROL SERVER • IMPERSONATE
- 14. 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
- 15. Secure Configuration –SQL Server
- 16. Starting with aSecure 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
- 17. 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
- 18. Other Ways toMaintain • Custom Scripts • 3rd Party Products • Periodic Checks. Don’t Rely on initial setup and PBM –ALWAYS audit security –Server settings important for compliance requirements
- 19. Secure Communication • Don’tassume network is secure, even if it’s “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)
- 20.
- 21. Encrypting Data atRest • Easy Button: Transparent Data Encryption • OS Options: • Encrypting File System (not recommended) • Bitlocker • Don’t 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.
- 22. Encrypting Data inthe DB • TDE and OS file level encryption don’t 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
- 23. Speaking of KeyManagement • 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.
- 24.
- 25. Default Trace andServer 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 • Deprecated
- 26. Extended Events • Canaudit for anything you should need • Can be made as lightweight as possible • Does require legwork to get right • Doesn’t send information to OS event logs by default • Easier solution: Audit objects
- 27. Audit Objects • Twolevels: • Server • Database (fine-grained) • Track events at both levels • Database level events: • Can also grab SELECT queries (who is accessing the data) • Don’t assume all access is through the application(s) • Targets: • File system • Application event log • Security event log (recommended)
- 28. What We Lookedat Today • Repeatable Processes (#3, #5) • User Security (#4) • Secure Configuration (#2, #5) • Auditing Access (#1, #4)
- 29. Further “Print” Resources: IDERAwhitepaper: https://www.idera.com/resourcecentral/whitepapers/security-and-compliance-solutions-for-hipaa Microsoft SQL Server Compliance whitepaper: https://www.microsoft.com/en-us/download/details.aspx?id=6808 Experis Finance whitepaper: http://www.experis.us/Website-File-Pile/Whitepapers/Experis/FIN_HIPAA-Complaince-with-SQL_050211.pdf Securing SQL Server, Third Edition Denny Cherry (book published by Syngress)