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

1

Agenda

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

2

Learning objectives

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

3

Background

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

4

ERP and EMR Security

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

5

SA in ERP and EMR

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

6

Approach to Sensitive Data Audit

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 (role-

based)

Socialize the concept of SA

Review sensitive access restrictions and validate with business owners

Review user access to sensitive activities / data over time

7

Approach to SOD Audit

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

8

SOD Conflict Matrix ERP

Example SOD matrix

ERP activities

9

SOD Conflicts Matrix EMR

Example SOD matrix

EMR revenue cycle activities

10

SOD Conflict Matrix EMR & ERP

Example SOD Matrix

11

SOD Matrix

Cross-application SOD matrix

Incorporates activities from in-scope applications

ERP and financial planning (post journal entry)

EMR (receive payment)

12

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

Limit enforcement of SODs to high risk SOD rules only. Identify other mitigating factors for medium or low risk SOD rules

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

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

Importance of continuous monitoring

Methods to monitor access

Manual monitoring

Application reports

Governance, Risk and Compliance (GRC) and Identity

solutions

16

SOD and SA in Healthcare

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)

17

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.