Gabriel Ducoing Eric Kosmos Diana Silva Justin Freiler ... · Tying It All Together! Samuel Pierre-Louis Director, Information Security 1 2012 DRJ Fall World September 10, 2012 1:30

Governance, Risk and Compliance –Tying It All Together!

Samuel Pierre-LouisDirector, Information Security

1

2012 DRJ Fall WorldSeptember 10, 2012

1:30 – 2:30 p.m.

Gabriel Ducoing

Eric Kosmos

Diana Silva

Justin Freiler

Stephanie Hilmes

Agenda

• University of Texas MD Anderson Cancer Center Profile (MD Anderson)

• Organizational Challenges• How is DR Program Tie into RA Program• Governance, Risk & Compliance General approach

– Unified Controls Matrix– Risk Management Program

• Disaster Recovery Program– DR Plan Structure– Criticality Assessment (CA)– Dovetail RA & DR within other Programs– DR Program Governance– DR Planning Life Cycle– DR Plan Testing– 2012 DR Integrated Technical Test

• Metrics Reporting• Current Efforts & Future Plans• Recap of DR Program• Governance, Risk & Compliance, Tying It All Together

MD Anderson Cancer Center Proprietary Information2

MD Anderson consistently tops cancer rankings

For the sixth year in a row, and the ninth time in the past 11 years, The University of Texas MD Anderson Cancer Center earned the No. 1 spot in U.S. News & World Report’s annual rankings of the best hospitals for cancer care.

http://www.mdanderson.org/

3

University of Texas MD Anderson Cancer Center

Mission:

To eliminate cancer in Texas, the nation and the world through outstanding programs that integrate patient care, research and prevention, and through education for undergraduate and graduate students, trainees, professionals, employees and the public.

Staff:

• 18,000 employees including 1,500 faculty

• 1,100 volunteer work force – 200,000 hours of service annually


Organizational Challenges

• Patient Care− 25,230 hospital admissions− Patients from all over U.S.A & all over the world− 594 average number of operating beds− Over 1 million outpatient clinical visits

• Research− Important scientific knowledge is rapidly translated into clinical care− The research is considered one of the most productive in the world

aimed solely at cancer− Over $600 million total research funding− In 2011, MD Anderson completed Making Cancer History®: The

Campaign to Transform Cancer Care, which raised 1 billion to support a variety of key initiatives relative to cancer research, patient care , etc.

• Education− 7,000 trainees participated in education programs− Accreditation by the commission on Colleges of the Southern

Association of Colleges and Schools affirms MD Anderson as a major teaching institution

5

Physical Presence

• Texas:

– 2 Regional Research Campuses in addition to MD Anderson’s main campus

– 4 Regional Care Centers around Houston

• Outside Texas:

– MD Anderson Radiation Treatment Centers at Presbyterian Kaseman Hospital (Albuquerque, N.M.)

– MD Anderson Orlando (Orlando, Fla.)

– Banner MD Anderson (Gilbert, Ariz.)

• International:

– Centro Oncológico MD Anderson International España (Madrid, Spain)

– MD Anderson Radiation Treatment Center in Istanbul at American Hospital (Turkey)



Complexities of Information Security Regulations

• Federal – Health Insurance Portability & Accountability Act (HIPAA), 21 Code of Federal Regulations (CFR) Part 11, 21 CFR Part 58

• State – Texas Administrative Code• University of Texas Policies – UTS Policy 165, University

Identity Management Federation• Payment Card Industry standard (PCI)• Sarbanes-Oxley • Etc.



Technical Complexities

• Platform disparities

• Hundreds of applications

• Thousands of servers

• Several data centers

• Centralized IT – about 700 employees

• Distributed IT – about 300 employees

• Ongoing development of new applications

• Continual infrastructure build-out

• Internal software development, e.g. EMR



Many Compliance Audits

To name a few:

• Federal Audits – HIPAA

• State Audits

• University of Texas Audits

• Internal Controls Audits

• Joint Commission Surveys

• PCI

• Other key audits



Point Assessment per Regulation

• Leads one to focus on a few regulations and neglect others

• Duplication of efforts on assessment

• Inefficiency

• Customer frustrations

• Resource constraints



Information Security Risk Management

• Risk Management

– Policies and Standards

– Risk Assessments and Vulnerability Assessments

– Disaster Recovery Program

– Training and Awareness


Information Security Risk Management Framework


Risk Assessment High Level Workflow


RAQ

Initiation

(Q1)

Tier 1

or

CMNF?

Application Owner

QA Readiness

Checklist

(Q5)

Risk

Assessment

(Q6)

RA QA

Closure

(Q7)

Risk

Analyst

Agrees?

App

undergoing

CMNF?

END

Action Items

Reminders

Escalation

Y

Y

N

N

Y NApplication

Definition

(Q2)

Application

Admin

(Q3AA)

Tier 1 Applications (Annually) , Any Tier Application needing CMNF, applications selected for Information Security QA, or any

application that has not been assessed a Tier level.

Tier 2 & 3 Applications

(Every two years)

CMNF

Clearance?

N Y

ASP

(Q3ASP)optional

Tier 1 Applications

(Every year)

Risk Assessment Workflow DRP Review Process


How is DR Program Tie into RA Program

15

Governance Risk & Compliance General Approach

16

MD Anderson Method

Risk Management in Light of All These Complexities

Perform individual Risk Assessment per regulation on a periodic basis, e.g. individual assessments for HIPAA, PCI, TAC, 21CFR Part 11, SOX, etc.

V.S.


Unified Controls Matrix

• Mapping of all Information Security regulations and some security best practices

• Enables one assessment to satisfy applicable regulations versus conducting a special assessment for each regulation

• Reduces the hundreds upon hundreds of regulatory control points to a smaller set

• Developed high level Policies for end users• Developed Operations Manual for system administrators• Developed Security Guidelines• Developed System Security Checklist• Developed Risk Assessment Questionnaires• Embedded throughout is the Disaster Recovery requirements


Unified Controls MatrixExample


HIPAA

regulatons

TAC 202

regulations

21CFR PART

11 rgulations

PCI

standards

SARBANES

OXLEY

regulations

ISO 17799

standards

Policy Operations

Manual

procedures

Guidelines Checklist Risk

Assessment

Questionnaires

a a a a a a a a a a

b b b b b b b

c c c c c c c c c c c

d d d d d d d

e e e e e e

f f f f f f f f f f

Documents Derived From Matrix

• Policy for the Use and Protection of Information Resources

• Information Resources Security Operations Manual

• Information Security Guidelines

• System Security Checklist

• Risk Assessment Questionnaires

• Embedded throughout these documents are the Disaster Recovery guidelines

• All documents map back to the Unified Matrix


Risk Management Program

• Define a Risk Assessment Process Workflow

• Inventory of all applications and assets ( name, owner, custodian and infrastructure that application is riding on)

• All Guidelines, Checklist and Questionnaire aligned with Unified Controls Matrix

• Risk Assessment Questionnaire incorporates Criticality Assessment

• Disaster Recovery is a collaborative and cooperative effort between Information Security and project teams


When is a Risk Assessment Required?

• New Project

• Existing application going through significant change

• Critical systems, annually

• Other systems, every other year

• Work closely with Change Management


Disaster Recovery Program

• Define a Disaster Recovery Planning Process Workflow

• Management DR Plan - Umbrella

• Inventory of all applications and assets ( name, owner, custodian and infrastructure that application is riding on)

• Criticality Assessment method for defining priority resource allocation

• All Disaster Recovery Guidelines, Checklist and Questionnaire aligned with Unified Controls Matrix




Background / Program History

• Business Continuity Planning (BCP) and Disaster Recovery are managed out of different divisions− BC managed by Finance

− DR managed by Information Services

• Some isolated DR activities, but no formal program, standards and scarcity of documented plans

• Very subjective system prioritization without dependency and infrastructure consideration

• More emphasis on getting DR application vs. process maturity and methodology

• Enterprise DR responsibilities transferred to Information Security and Program development began mid 2006



Challenges and DR Pitfalls

• BCP’s Business Impact Analysis (BIA) was still in progress

• Develop criteria to prioritize systems and allocate DR resources

• Develop a standardized DR framework for all IS areas

• Develop methodology and processes that fit the organization

• Mandate DR processes from a vendor’s application vs. developing processes that fit the institution and finding an application that facilitates it.

• Work within budgetary and resource constraints

• Avoid the single DR Manual Shelfware

Typical DR Plan Model


Lack of Ownership

Large Binder Plan

Centrally Managed


Disaster Recovery Plan Structure

Drives accountability and ownership

Why Criticality Assessment?

• CA is done as part of the RA process

• How it plays into DR for priority setting and resource allocation

• On-going process to manage and prioritize internal departmental resources

• TAC 202 defines frequency of risk assessments based on criticality

• Prioritize and allocate resources by other departments within the organization


Pitfalls of No Criticality Assessment

• Lack of objective criteria for determining critical systems

• Political arm twisting where those with the most political clout “win”

• Attaching one’s sense of worth to being placed on the Critical Systems list

• Over committing the institution’s finite resources and setting false expectations

“Many systems are important, but only a few are critical

just after a disaster.”


Criticality Assessment Methodology

• Analyzed the primary mission of the business

• Developed objective criteria, 15 Impact Factors, for evaluating systems based on our mission.

• Developed scoring system to more objectively determine one’s tier

• Vetted the methodology through the governance process

• Involved IT and business side in assessing systems

• Having documented criteria stops backdoor and political arm twisting attempts to become a Tier One system

• Incorporated CA into the Security Risk Assessment Process


• Established 3 levels/tiers of classification based on results

• Rate systems against criteria

• Ratings drive institutional requirements and resources

• Approval and buy-in by Senior Operations Team– Considers the mission and core business needs

– Defines criteria for identifying how a system enables MD Anderson to fulfill its mission and core business requirements

– Establishes RTO and expectations for tiers. Tier One target RTO of 8 hours


Criticality Assessment Methodology

Criticality Assessment Tier Level Distribution

32

• Identified infrastructure resources required to support Tier One systems

• Focus Information Security and institutional resources on Tier One systems and their supporting infrastructure

• Provide training and guidance to Tier Two and Three systems

• Does NOT minimize importance of Tier Two and Three systems.

• Disaster Recovery strategies based on Criticality Assessment

• Everyone is accountable for developing their DR plan!


DR Plan Development

• DR Plans are owned by application owners / custodians

• DR centric – User empowerment

• Application or System Owners are responsible for the accuracy, completeness, content and testing of the disaster recovery plan.

• While Information Security provides guidance to complete the plan, it is not responsible for its accuracy, completeness and content.

• In addition, Information Security does not guarantee the proper execution of the plan or any audit findings.


Application or System Owner’s Responsibility

Selling the RA & DR Program

35

Organizational Buy-In

• Develop partnerships within the organization

• Presentations to the following:

– IT Town Hall

– IT Leadership

– Senior Operations Team

– Information Services Executive Team

• Internal Communications via emails and Employee Notes


Dovetail RA & DR within Other Programs

• Change Management Process

• IT Governance Process

• IT Standards Work Group

• Technical Review Work Group

• Solutions Engineering Team

• Information Security Work Group

• Infrastructure Steering Committee

• Business Continuity Executive Steering Committee

• Emergency Management Process

• Information Security Compliance Committee

• Contract Services


How DR Process Feeds Information into Other Processes

• Risk Assessment Plan is defined by the Criticality Assessment

• Tier 1 applications go through full risk assessment with Risk Analyst validation

• Tiers 2 and 3 applications go through security self assessment

• All new applications or applications going through significant change go through full risk assessment with Risk Analyst validation


For Example: Risk Assessment Plan


Implementation of DR Program

• Developed DR Plan Template− Initially developed in MS Word then converted to DR Program

Management Software− Focused on people embracing DR methodology and not on

learning a software package

• Developed Plan Testing Templates− Facilitates testing and validation of DR plans− After Action Report and tracking of gaps and open items

• Selected DR software in accordance to defined requirements:− Web based & intuitive− Integrates with existing data sources to streamline process− Able to conform to MDACC DR methodology

• Leveraged DR Best Practices− Tweaked to fit the institution’s environment and DR Program

maturity

• All new applications or applications going through significant change go through full risk assessment and criticality assessment

• New applications must complete a DR Plan within 6 months after go-live date

• Developed Compliance Status Reports for review by management

• Non-compliance to the DR Program requirements are flagged and escalated


Disaster Recovery Program Governance

Disaster Recovery Planning Life Cycle



Established Disaster Recovery Forum Work Group

• Included the top tiered systems and infrastructure plan owners

• Identified inter-dependencies / data flow of critical systems

• Determined system recovery sequencing and DR process gaps

• Holds personnel accountable for owning the recovery of their systems (e.g. peer-pressure)

− Status progress on plan development

− Status progress on plan testing and remediation of plan gaps

− Define current capable RTO


Applications & Interdependencies


Sequence of Applications / Infrastructure Recovery

• DR Plan Program Requirements

– All applications / systems must have a DR Plan

– Review DR Plan of all tier at least once annually

– Tabletop testing for all tiers annually

– Technical testing: annually for Tier 1; bi-annually for Tier 2; not required for Tier 3 but recommended

– After action report is generated for follow-up

• Integrated technical test annually to validate

− Tier One systems DR plan documentation

− Inter-dependencies and interfaces

− Recovery Time Objective (RTO)

− Communications during recovery effort

• Increasing complexity of integrated testing


Disaster Recovery Plan Testing

• 2012 Integrated Technical Test

– Included Tier One applications and inter-dependencies

– Validated the sequencing of application recovery

– Verified applications connectivity and transaction processing

– Validated application recovery time objective

• Test Plans / Timeline / Checklists

− Developed test plan, test scripts and timeline checklists

− Prepared an integrated test script timeline and compile the test tasks checklist

− The Command Center Support Team collaborated with test team members to track completion of the test tasks and documented any issues occurred on the checklist


2012 DR Integrated Technical Test Execution

• Outcome

– Validated the prescribed eight-hour RTO (Recovery Time Objective)


2012 DR Integrated Technical Test Result

• Future Test

– Infrastructure components such as VPN, SAN, etc. will be included in future test

– Continue to introduce new complexities and incrementally add new twists moving forward

– Continue to test and validate DR Management decision making timeline

Metrics Reporting

• Compliance Reports (based on DR Program requirements)– Shows compliance information of each application DR plan

development status– Shows compliance information of each application DR plan being

maintained and tested

• Service Delivery– Risk Assessment cycle time metrics for each step of the process– Disaster Recovery planning, testing and after action items follow up

• Operations improvement Reports– Change Management Readiness Level for each application going

through Change Management– Server assignment for application report– Programs alignment report (DR and Risk Assessment Tool)

• “Wall of Shame” Reports– Non-compliance reports



DR Plan Compliance Report Example

Current Efforts

• Metrics reporting

• Align all legacy system risk assessment with DR Planning

• Maintain DR compliance of all systems

• Unified Controls Matrix is an evergreen process

• On-going system integration of RA and DR Programs

• Increased visibility within the Organization

• Technology Saturation


Future

51

Future


• Continue to integrate DR Management process with the Security Risk Management system

• Incorporate DR program matrix into an Information Security executive dashboard

• Continue to report metrics and program information through the governance process

• Continue to provide “priority” service to Tier One system owners; while providing training and guidance to lower tier system owners

• Continue to conduct institution-wide integrated DR test, progressively adding more complexity to scenario testing

Information Security Risk Management Dashboard

• Consolidated Risk Management view of the organization• Provide executives and business owners roll up

dashboard reporting• Executives and plan owners can view reports on demand

that are appropriate to their areas of responsibilities• Integrated views of security posture within their areas of

responsibilities • Drill down capability


Information Security Dashboard


Server &

Desktop

Compliance

Enterprise

Security

Metrics•Virus•SPAM etc.

Self-Service

Scanning•Host•DB•Web App.

Disaster

Recovery

Application

Risk

Assessment

Information

Security

Dashboard

Conclusion

55

Recap of DR Program


• Integrate DR Planning into RA Process

• Established framework with individual system plans and an overarching DR Management Plan

• Implemented DR management software that fits the institution’s program. Avoid the single DR Manual Shelfware.

• Criticality Assessment Tier Level Distribution – prioritizing systems and allocating DR resources. Mitigated political arm twisting

• How DR Process Feeds Information into and back from other processes

• Dovetail RA & DR within other programs

• Implementation of DR Program. Outlined DR Planning Life Cycle

• Established DR Workgroup Forum – collaboration and accountability

• Identified system interdependencies and recovery sequencing

• DR Plan Testing and Integrated Technical Test• Developed and deliver DR Program metrics Reporting

Key Take Away

• DR is an integral part of Risk Management framework

• Information from Risk Management feeds into DR

• DR provides information to other programs such as – Change Management Process

– IT Governance Process

– Information Security Work Group

– Infrastructure Steering Committee

– Business Continuity Executive Steering Committee

– Emergency Management Process

– Information Security Compliance Committee

– Contract Services

• Objectively define resource tier/criticality


Governance Risk Compliance & DR – Tying It All Together

58

POLICIES

PCI

SOX

21CFR 58

VA

GUIDELINES CHECKLIST

QUESTIONNAIRE

Contact Information


Contact Information:

Samuel Pierre-LouisDirector, Information Security

Email: [email protected]

Rene SanchezManager, Risk Management

Information SecurityThe University of Texas MD Anderson Cancer Center

Office – 713-745-9038Email: [email protected]