exception management program isaca – geek week conference august 11, 2014

Exception Management Program

ISACA – Geek Week ConferenceAugust 11, 2014

Children’s Healthcare of Atlanta

Agenda

IntroductionsException Management 101Program ObjectiveTraditional Pain PointsMethodology Risk Control FrameworkWorkflow and RecertificationSummary

2


Introductions

• Russell Hyllested, CISM, CISSP Senior Information Security Specialist Children’s Healthcare of Atlanta

• Ricardo Binns, Information Security Specialist Children’s Healthcare of Atlanta

3



Not-for profit healthcare system and one of the largest pediatric clinical care providers in the country:860,849 Patient Visits in 2013361,927 Patients (from all 159 GA

counties)3 world-class pediatric hospitals (561

licensed beds), 24 neighborhood locations, physician group practices, and other related facilities

Over 8,700 employees, 1,700 pediatric physicians, and 6,500 volunteers 5

6

Exception Management


Exception Management 101Organizations develop, publish and

implement administrative, technical and physical safeguards in an effort to adequately protect the confidentiality, integrity and availability of its patients, customers, employees, and partner information.

In circumstances when a particular policy or standard; security program requirement; or security best practice cannot be fully implemented; an exception management program is needed.

7


Exception Management 101There is a difference between Risk

Acceptance versus Exception ApprovalProgram requires organizational

management buy-in Each exception request must be analyzed

in order to determine the potential impact and likelihood that it can be exploited (risk assessment)

8


Exception Management 101 Impact exposure may include potential

harm to the following areas of the organization: Financial (Revenue, Expenses and Credit risk)Reputation/BrandLegal Liability (Civil and Criminal)Compliance (Regulatory/Statutory)Operational (Functional and IT Systems)

Enterprise adoption of formal end-to-end exception process

9


Program Objective

Provide a formal, repeatable and scalable program by incorporating the following elements:

Request process must be accessible to all business areas

Uniquely identify and catalog each exception request

Utilize a risk assessment framework to assign risk values

Articulate exception risks in non-technical terms

Risk acceptance is correlated to the risk exposure

Proper approval and management authorization

Exception expiration is dictated by the level of risk

10


Traditional Pain Points: 1 of 2When do I need an exception?Can’t find a previously “approved”

exception E-mail Helpdesk tickets PMO project notes Meeting minutes or… (gulp) Verbal

Rubber stamp approvalsWhy am I approving this exception?

Organizations typically believe InfoSec should “Approve” an exception

Can’t articulate the risk of an exception request 11


Traditional Pain Points: 2 of 2Not dynamic enough to cover items that

are “required” but not explicitly defined. Examples: Inability to apply security patches or standard configurations

due to technical issues (e.g., instability of legacy applications, OS no longer supported, etc.)

Risk exposure resulting from a vendor relationship (e.g., inability to perform adequate security diligence or accepting a vendor control weakness)

Difficult to manage the volume exception requests Once you stand up a program, exceptions will come fast and

furious

Recertification Tsunami Every year for…eternity!!! 12

13

Methodology


Methodology 1 of 4

Define when an exception is required. Non-compliance/accordance to the following:o Policieso Standardso Information Security Program Deltaso Best Practice implied but not explicit

Define how an exception is submittedo Helpdesk ticketo E-mail Distribution List

14


Methodology 2 of 4

Define how the exception workflow process for new, renewal and expirations will be accomplishedo Include an internal Service/Operating

Level Agreement (SLA/OLA) o Ensure inter-departmental dependencies

are addressed (e.g., Helpdesk SLA/OLA)Define where exceptions will be cataloged

o SharePointo Databaseo Excelo “Home grown” application 15


Methodology 3 of 4

Define how an exception is risk ratedoDevelop Risk Control FrameworkoRecommend Semi-quantitative

Assessment o Document Behavior, Risk and Threato Create Customized Impact Matrixo Define Likelihood/Frequencyo Determine Inherent Risk and Control

Effectivenesso Result: Residual Risk Score

16


Methodology 4 of 4

Define who can accept risk on behalf of the organizationo Should be risk driven: Manager,

Director, SVP, Board approval/Audit notification

Define when an exception requires recertification

oRisk dependent: Lower risk = longer expiration date

oMajor environment changes may also necessitate the reevaluation of an exception 17


Prepare to Collaborate

Requires buy-in from stakeholders to understand risk acceptance vs exception approval

Work with CIO, CFO, Compliance, Risk Management and Audit to develop Impact Codes. This cannot be developed in a “bubble”

Describe the need to update helpdesk procedures, create ticket queues, procedural documentation, etc.

Train/Communicate go-live dates via e-mail, intranet, lunch and learns, Computer Based Training (CBT), etc. to the entire organization

18

19

Risk Control Framework


Develop a Risk Control Framework

Defines how Information Security will assess and determine the residual risk of an exception request

Risk assessment framework should be based on industry best practice but customized to meet organizational needs Reference for developing a risk control framework:

National Institute of Standards and Technology (NIST) Special Publication 800-30: Guide for Conducting Risk Assessments

Enables you to articulate the level of risk each exception

Repeatable process that minimizes risk misunderstandings

20

http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf




Sample Risk Evaluation Tool

21


Risk Control Framework (1 of 2)

22


Risk Control Framework (2 of 2)

23


Sample Exception Analysis

24


Evaluating an Exception (1 of 2 )

25


Evaluating an Exception (2 of 2 )

26

27

Workflow & Recertification


Workflow

Submission of an exception request should be accessible to all users

Plan the recertification and expiration strategy before you go live

Provide FAQ and/or tip sheets to end usersDefine internal service level agreementsDocument the workflow! Improve as needed

28


New Exception Request

29


Recertification and Expiration

Exceptions should be valid for a finite period of time and be reevaluated upon expiration

Residual risk score can help you determine the maximum time an exception can be valid

Examples:1- 40: Manager Approval required – 3 Years 41-52: Director Approval required – 2 years53-109: SVP Approval required – 1 Year110-188: Compliance committee and/or Board

approval required; and Audit team notification – 1 Year or less 30


Recertification Workflow

31

32

Summary


Summary

Exception process must be accessible and understandable by all colleagues

Exception management requires a risk assessment approach to accurately quantify risk

Proper exception management enables risk acceptance to occur

Risk appetite can only be understood by collaborating with key organizational leaders

Document entire program Improve as needed 33

exception management program isaca – geek week conference august 11, 2014

Documents

exception management

exception request

exception process

exception risks

exception approval program

risk values

level of risk

profit healthcare system