1
SEGREGATION OF DUTIES (SOD) AND SENSITIVE ACCESS (SA) ACROSS APPLICATIONS MATT SCHIEFER, CISA MANAGER DELOITTE ADVISORY OUSAMA LAKHDAR-GHAZAL, CISA, PMP MANAGER DELOITTE ADVISORY AHIA 34th Annual Conference – August 30 – September 2, 2015 – Portland, Oregon
www.ahia.org
Agenda 2
Learning objectives Background Enterprise Resource Planning (ERP) and Electronic Medical Record (EMR) security Sensitive access in ERP and EMR Approach to SA audit Approach to SOD audit SOD conflict matrices SOD challenges and lessons learned Tools
Learning objectives 3
Explain the concepts for sensitive access and segregation of duties Security in an EMR and ERP related to SOD and SA Understand the approach for sensitive access and segregation of duties reviews Tools available to identify conflicts
Background 4
Definitions SA:
access to an activity that is deemed sensitive and for which access should be restricted because it either grants access to view or manipulate data in a way that can create a risk to the organization.
SOD:
the combination of two activities that combined create a potential risk or a potential conflict of interest.
Areas of Interest Operations:
Clinical, Financial Back-end: Change Management, Database Access
ERP and EMR Security 5
Similarities Security
is module/application-based Security is based on roles Users typically have access to multiple modules/applications
Differences Business
process-driven vs. operating process- driven
SA in ERP and EMR 6
What do we consider sensitive access? ERP Access
to view personally identifiable information (PII) in application or database Access to business activities (e.g., post journal entries) EMR Access
to view protected health information (PHI) or PII in application or database Access to perform certain activities within the application
Update PHI/PII Create/update/delete access
Approach to Sensitive Data Audit 7
Understand what SA means to your organization
Understand what activities are deemed sensitive by business owners
Translate the activities into specific security design
Perform a review of users with SA
Determine if such access is needed by the identified users (rolebased)
Socialize the concept of SA
Review sensitive access restrictions and validate with business owners
Review user access to sensitive activities / data over time
Approach to SOD Audit 8
Determine in-scope modules/applications Define specific business functions within the modules/applications Translate the activities into specific security design Define SOD conflicts and create SOD matrix Socialize and validate conflicts with business/application owners Assess impact and risk of SOD conflicts Review remediation/mitigation of SOD conflicts
SOD Conflict Matrix ERP 9
Example SOD matrix ERP
activities
SOD Conflicts Matrix EMR 10
Example SOD matrix EMR
revenue cycle activities
SOD Conflict Matrix EMR & ERP 11
Example SOD Matrix
SOD Matrix 12
Cross-application SOD matrix Incorporates ERP
activities from in-scope applications
and financial planning (post journal entry) EMR (receive payment)
SOD Challenges 13
Challenges
Workaround
Resource Availability Smaller organizations units lack man power to carry out the activities separately.
Identification of mitigating controls (such as reporting to review accuracy) is an option when separation of access is not possible.
Operational Performance Workflows (such as a vendor approval workflow) may be implemented to introduce added control where separation of responsibilities isn’t feasible.
Perform a full business process risk assessment and only implement workflow approval processes where the risks merit the process impacts. Also, set thresholds (e.g., define minimum dollar amount) where workflows become required.
Too Many/Redundant Mitigating Controls Some organizations apply a significant volume of mitigating controls that can become burdensome to perform.
Perform a full business process risk assessment and only implement controls where the risks merit the process impacts. Weigh options of adjusting rule set to address lower risk SOD violations.
Reviewing SOD at lowest level Some tools can analyze SOD at the role level, but not at a lower level (e.g., security point, transaction code, etc.)
Manual processes may need to be implemented to supplement use of automated tools. Thorough SOD reviews should consider application-application, role-role, and security point-security point conflicts.
False Positive SOD Violations SOD rule sets (if not configured properly) can produce SOD violations that aren’t intended. These false positives can produce needless access clean ups and mitigating control application.
While false positives can be difficult to entirely avoid, it’s important to be thorough when defining activities. (e.g., only add transactions or permissions that truly constitute access to the activities)
SOD Lessons Learned 14
Risk ranking
Firefighter access
Determine whether firefighter access should be subject to SOD restrictions. Since this access is often powerful and wide open, it may be necessary to address risks with the firefighter log reviews
Cost/benefit analysis for mitigating controls
Limit enforcement of SODs to high risk SOD rules only. Identify other mitigating factors for medium or low risk SOD rules
Perform cost benefit analysis when implementing mitigating controls to determine if the risks justify the ongoing cost of sustaining the control
SOD rule set design
Associate relevant transactions to corresponding SOD Business activities Identify/Include relevant cross-application business transactions to corresponding business activities Obtain business sign off when implementing mitigating controls
Example of Available Tools 15
Source: Gartner, “Market Guide for SOD Controls Monitoring Tools”, 28 April 2015
Monitoring user access 16
Importance of continuous monitoring Methods to monitor access Manual
monitoring Application reports Governance, Risk and Compliance (GRC) and Identity solutions
SOD and SA in Healthcare 17
Potential Solutions:
Develop a repeatable approach Socialize the importance of SOD and SA reviews with leadership Partnering with other departments Multiple tools available (e.g., automation)
Save the Date September 11-14, 2016
35th Annual Conference Atlanta, Georgia
Appendix A: Acronyms 19
Acronym
Description
SOD
Segregation of Duties
SA
Sensitive Access
PII
Personally Identifiable Information
PHI
Protected Health Information
ERP
Enterprise Resource Planning
EMR
Electronic Medical Record
20
Product names mentioned in this document are the trademarks or registered trademarks of their respective owners and are mentioned for identification purposes only.
This presentation contains general information only and Deloitte is not, by means of this presentation, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This presentation is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte shall not be responsible for any loss sustained by any person who relies on this presentation. About Deloitte Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients. Please see www.deloitte.com/about for a detailed description of DTTL and its member firms. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting.