You are on page 1of 44

NCI-Center for Biomedical Informatics and Information Technology Enterprise Security Program Concept of Operations

January 14, 2010

V.11

Distribution Copy

1 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

Table of Content
I. DOCUMENT HISTORY ............................................................................................................................ 2

II.

DISTRIBUTION LIST ................................................................................................................................ 3

III.

PURPOSE AND SCOPE ............................................................................................................................ 4

IV.

MISSION ................................................................................................................................................ 5

V.

BUSINESS OBJECTIVES ........................................................................................................................... 7

VI.

SECURITY PROGRAM OVERVIEW ........................................................................................................... 8

VII.

OPERATIONS GOVERNANCE FOR NCI-CBIIT ENTERPRISE SECURITY PROGRAM ............................... 11

VIII.

PROPOSED ESP FRAMEWORK ......................................................................................................... 14

IX.

ESP PERFORMANCE MEASUREMENT ................................................................................................... 25

X.

ADDITIONAL STAKEHOLDERS .............................................................................................................. 28

XI.

CREDITS .......................................................................................................................................... 29

XII.

APPENDICES.................................................................................................................................... 30

XII.

REFERENCES.................................................................................................................................... 44

I. Document History
Distribution Copy

2 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations Version V.1.0 V.2.0 V.3.0 V.4.0 V.5.0 V.6.0 V.7.0 V.8.0 V.9.0 V.10 V.11 Date March 26, 2009 April 23, 2009 July 29, 2009 August 05, 2009 August 21, 2009 September 18, 2009 September 23, 2009 October 05, 2009 October 27, 2009 December 2, 2009 Letter of Endorsement Comments First draft Content review Content review Content review Content review Content review Content review Content review Content review Content review Endorsement Letter added

II. Distribution List


Stakeholder Ken Buetow George A. Komatsoulis (acting) George A. Komatsoulis Dwayne Forquer Wendy Patterson Charlie Mead Caterina Lasome Marsha Young Avinash Shanbhag Eric Williams Bruce Woodcock Braulio J. Cabral NIH community NCI Community CBIIT/caBIG Community Title CBIIT Director CBIIT CIO/NCI CBIIT Deputy Director CBIIT Chief of Staff/NCI CBIIT CLO/NCI CBIIT CTO/NCI/BAH CBIIT COO/NCI caBIG Security Policy Project Manager/BAH CBIIT Director Engineering NCI/CBIIT Infrastructure Manager NCI/CBIIT ISSO NCI/CBIIT ESP Coordinator NIH NCI CBIIT/caBIG Interest/Stake Sponsor Owner Contributor Advisory Contributor Contributor Contributor Advisory Advisory Advisory Contributor Users Users Users

Distribution Copy

3 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

III.Purpose and Scope


The main purpose of the NCI Enterprise Security Program (NCI ESP) is to protect the NCI enterprise assets from threats to confidentiality, integrity, and availability. Any item of value to the organization is considered an asset, including; data, information stored in NCI-hosted systems and applications, some of which are considered protected health information (PHI), personally identifiable information (PII), and intellectual property rights, as well as the supporting infrastructure. It is the responsibility of this program to provide the necessary means to protect these assets while facilitating ease of access to data and services for authorized individuals. The NCI ESP implements federal policies, procedures and guidelines for the NCI and its hosted systems and provides guidance concerning security requirements to developers of caBIG applications and services. The NCI Center for Biomedical Informatics and Information Technology (CBIIT) OCIO has program responsibility for the NCI ESP. The scope of the security program is to plan, promote and coordinate the execution of all security related-activities across the NCI enterprise leading to the goal of protecting confidentiality, integrity and availability for NCI-hosted systems and data, as well as the protection of NCIs intellectual property and reputation pertaining to matters of security. Activities within the scope of the program include but are not limited to development and implementation of security policies, guidelines, and standards; establishment of processes and procedures to implement policies; and promoting security awareness for all stakeholders. The enterprise includes systems hosted by NCI and its contractors, such as caGrid core infrastructure and services, and NCI physical information infrastructure (LAN, servers, data storage, etc.). Successful operation of the NCI ESP requires the participation of NCI internal and external entities and organizations and the proper identification of roles and responsibilities related to the security program. The distributed nature of NCI staff makes communication and coordination imperative to the success of the program. Another key element in the successful implementation of the program is a roadmap or framework that guarantees the planning, execution and validation of the following topics. Compliance, privacy, risks assessment, assets classification and ownership, physical and environmental security, business continuity and disaster recovery, network security, access control, authentication, Encryption/key management, segregation of duties, auditing/logging/monitoring/review software security, incident response, change management, system development life cycle and security awareness.

Distribution Copy

4 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

IV.

Mission

The mission of the NCI Enterprise Security Program is to ensure that the full lifecycle and breadth of a robust security program functions well to serve the business needs of The NCI community. The program also looks to providing value-added services to NCI business entities by engaging in the following activities: Maintenance of relationships with business areas such as workspaces for information assets owners. Facilities for physical security and asset management Compliance for legislation and regulations and privacy Information technology for IT operational management Software engineering for security within the SDLC Representation for security relevant forums Security consultancy to business areas Security support to business projects

This mission will be accomplished through a unified security framework that encompasses: The overarching security policies that govern NCI infrastructure including but not limited to the policies inherited from NIH Security Plan, policies governing the caGrid core infrastructure services, the policies and procedures governing the users of the caGrid core infrastructure services, and the policies and procedures governing all NCI-hosted applications, services and data and the users of those capabilities. The operational programs that maintain the internal and external agreements and memoranda of understanding/agreement with other entities outside of CBIIT. Guidelines and standards to validate compliance with the policies and technical implementation of the trust fabric, as well as compliance with relevant statutes and rules governing federal and non-federal information systems. The NCI security services infrastructure that implements the policies and the operational procedures that govern development, deployment and use of the security services infrastructure. The program initiatives are driven from the strategic business goals and can be summarized as; the need for compliance with federal and local regulations, a secured data sharing infrastructure, federation of services, scalability, clarity and easy of entry. The program promotes a synergy between policy, engineering, technology and compliance to serve these needs. The graph below depicts a conceptual view of the ESP different components.

Distribution Copy

5 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

Fe r de

an

al

Pl

cu Se

te gi

rit

ra

y u eg R

St

ne s

Communications

ti o la

Bu si

ns

Train

Enterprise Security Governance (ConOps)


Hardware (Servers, OS)

Standards, Guidelines & Procedures

Outr

ing

& each

urity

ss rene Awa

S ec

Business Information & Data

Security Policy and Compliance DSSF

Business Needs Compliance Middleware Federation Scalability (caGrid, apps) Clarity Easiness

Physical Infrastructure (LAN, Building, Personnel)

SDLC Security ECCF Framework

IT

Se cu

rit y

NCI-CBIIT Enterprise Security Reference Model: A Business-driven Approach The success of this mission requires the active participation of all stakeholders, the understanding of the different roles and responsibilities for each stakeholder and the willingness to work together for a common cause. Stakeholders include; Executive Management Team (CTEAM) which includes; Director COO, CTO, CIO, and CLO and the Chief of Staff. Engineering team including; Director of software engineering, Director software architecture, Director Quality Control, Director software deployment Infrastructure Engineering and Operations team responsible for implementing and enforcing the security polices pertaining to; network operations, software maintenance, validations and access control, deployment, and change management caGrid Administration team. Responsible for the operational management of the various agreements between the NCI and external parties that memorialize commitments to various aspects of the ESP including such documents as Memoranda
Distribution Copy

En te

rp

ris

G ov er

ipa

tio n

mm Co

na nc

Pa rtic

NIH/NCI Engineering & Operations Baseline Security Controls

ity un

k ac db ee F

C om un m ity ee N ds

6 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations of Agreement, caGrid node Host agreements, NCI web services use agreements, inter NIH agreements, etc. Office of the Chief Information Officer. Responsible for developing and implementing the NCI enterprise wide security policies and procedures including those related to the implementation of FISMA in accord with HHS and NIH umbrella security programs. Enterprise Security Program Coordinator, responsible for the overall coordination of the security program among all teams across the NCI and across the full life cycle of the ESP from policy development through the development of security services that implement the policies and procedures and the implementation and compliance of those services.

V. Business Objectives
From a business perspective, the Enterprise Security Program is required to adhere to the following guiding principles: 1. Compliance: The program must enable compliance with Federal security mandates for those elements of the enterprise services that are hosted by NCI-CBIIT and it must facilitate compliance by users of the services and applications with applicable federal, state and local laws, regulations, policies and other requirements. 2. Federation: The infrastructure must allow the secure sharing of identity information between trusted participants and federation of authorization decisions by local data stewards. 3. Scalability: The infrastructure must be capable of scaling up to an arbitrary number of users and services with minimal disruptive redesign of the infrastructure. 4. Clarity: The implementation of the infrastructure must provide understandable guidance to ensure that providers of data understand the necessary level of protection appropriate for various types of data. 5. Ease of entry: The infrastructure must provide the minimum barrier to entry for data sharing commensurate with the sensitivity of the information that is being shared and enable appropriate secured access controls. It is recognized that these guiding principles may at times need to balance against each other. The Enterprise Security Program Framework promotes an integrated approach to security, a security framework driven by the business needs at an enterprise level. The program
Distribution Copy

7 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations encompasses the creation, organization, and execution of four subsidiary objectives that support the overarching objectives of the program: 1. Implement security policies inherited from NIH Information Security Plan and create a policy plan that includes any requirements not covered by the NIH ISP. The policies provide the rules that govern the infrastructure development and implementation to allow and encourage entities to exchange information via a trusted security infrastructure. This framework must allow for the creation of a trust fabric that does not require specific point-to-point trust agreements, but rather is capable of offering a set of mutual trust agreements. This objective is addressed below in Section VII (Security Program Overview Security Policy and Compliance. 2. Create a technical infrastructure that includes the guidelines, standards and procedures, to implement and enforce the policy framework. This objective is addressed in Section V (Security Program Overview. Security Processes and Procedures. 3. Define a set of best practices and other enabling processes that will allow individual providers of data services to implement the technical infrastructure in a way that is consistent with the policy framework. This objective is addressed below in Section V (Security Program Overview. 4. Develop and disseminate informational materials to convey security policies, provide user templates and checklists, explain automated and non-automated (i.e., executed off-line) agreements in use and educate NCI users and other stakeholders interested in understanding the security policies and infrastructure elements of the Enterprise Security Program. This objective is addressed below in Section VII (Security Program Overview - Security Outreach and Awareness 5. Finally, the Security Program looks to implement these procedures across NCI and validate compliance. This objective is addressed below in Section VII (Security Program Overview

VI.

Security Program Overview

The NCI Enterprise Security Program is designed to integrate and coordinate all information system security related activities. The program is managed by the Enterprise Security Program (ESP) Coordinator under the auspicious of the NCI OCIO and will be accountable to CBIIT leadership for developing integrated project plans, monitoring execution of planned
Distribution Copy

8 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations tasks and ensuring that the security infrastructure supports CBIIT security program objectives. As discussed in more detail below in Section X (Management of CBIIT Enterprise Security Program), the ESP Coordinator will work closely with a number of individuals and groups that have various responsibilities for the elements and tasks including in the ESP umbrella program. The NCI Enterprise Security Program includes: a. Security Policy i. Development of procedures and standards for effective implementation of NCI Information Security Plan. ii. Development of business level security policies related to CBIIT and caGrid services, service providers and users. iii. Development contract/trust agreements for caGrid users

b. Security Engineering and Operations i. Determines security models in terms of privacy, confidentiality, integrity and availability ii. Incorporate security policies into the software development life cycle (SDLC) iii. Help in the design, development and implementation of security guidance, standards, and procedures to implement and validate the security policy. (See caBIG Infrastructure Security Implementation Model for more details) c. Security Outreach and Awareness i. Establish NCI Web Security Presence ii. Strategic Communications from Program Office/CIO/ISSO iii. Development of security awareness material including and outreach sessions.

A. Security Policy
The scope of the security policy is limited to NCIs compliance with Federal information security requirements for NCI-hosted services. The policy framework for the NCI Enterprise Security Program includes the NCI implementation of NIH security policies as well as the development of the security policy elements of the caBIG Data Sharing and Security Framework (DSSF).
Distribution Copy

9 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations The following task areas are included in the security policy part of the NCI ESP: Development of the security policies framework applicable to all NCI services, applications including but not limited to caGrid core security services including: 1. caGrid Trust Agreements, contracts or agreements with Credential Providers where needed 2. Identity and Privilege Management policies (Authentication and Authorization Policies) The security policy activities will be articulated in the following major documents that flow from the NIH and HHS policies:

NCI Enterprise Security Policy - Describes federal policies and procedures that flow from the NIH Enterprise Information Security Plan and other laws, regulations and policies that govern the provision and use of CBIIT supported NCI infrastructure and services, including federally managed systems and all users of those systems. caBIG Security Policy Statement for caGrid (the Thin Book) Describes the NIH, NCI and federal-wide policies that govern the provision and use of the caGrid infrastructure specifically for users of the caGrid infrastructure. Serves as the outward facing description of the NCI IT security policy for users of caGrid. caBIG Security Policy for caGrid Handbook and Toolkit (or the Thick Book), an implementation guidance document that provides further detail to the caGrid policies and that functions as a how to manual for caGrid service providers and users.

B. Security Engineering and Operations This group of tasks focuses on developing, implementing and deploying the security infrastructure as informed by the security policies. Specific task areas initially defined include: 1. Security Monitoring & Audit Model 2. Certification and Accreditation Program Management at the infrastructure (network) level, systems and applications level. 3. Compliance Assessment 4. Configuration Management and Control 5. Contingency planning including: a. Business impact analysis b. Business Continuity plan c. Disaster Recovery plan
Distribution Copy

10 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations d. Security Bridge notification plan e. Plan maintenance 6. Design caBIG Infrastructure Security Framework (trust fabric) (See caBIG Security Infrastructure Services ConOps Appendix C) 7. Software Development Life Cycle (SDLC) Security framework C. Outreach and Awareness of Security Program These tasks focus on developing materials to inform and guide NCI and caBIG participants and the users and other stakeholders of security services. These tasks also include working closely with the Documentation and Training Workspace and with the DSIC and caGrid Knowledge Centers to develop and disseminate materials and to conduct proactive outreach to the caBIG community to mentor participants in using and understanding the materials and the caGrid infrastructure security services. Specific task areas initially defined include: 1. Strategic Outreach and Awareness plan, including: a. b. c. d. Establish NCI/caGrid Web Security Presence Strategic Communications from Program Office/CIO/ISSO Security Awareness and Outreach Sessions Compliance/Trust Agreement Notifications & Reminders

VII. Operations Governance for NCI-CBIIT Enterprise Security Program


To plan and coordinate the execution of the security program, the Enterprise Security Program (ESP) has been organized under the ESP Coordinator who will provide the continuity required. The ESP Coordinator informs the NCI CIO on all aspects of the Enterprise Security Program and works closely with a number of individuals and groups that have various responsibilities for the elements and tasks included in the ESP program and its umbrella program the NIH EISP. The Enterprise Security Program will adopt the SABSA framework to organize the enterprise-wide security program. The SABSA Institute describes this security framework as follows: SABSA is a model and a methodology for developing risk-driven enterprise information security architectures and for delivering security infrastructure solutions that support critical business initiatives. The primary characteristic of the SABSA model is that everything must be derived from an analysis of the business

Distribution Copy

11 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations requirements for security, especially those in which security has an enabling function through which new business opportunities can be developed and exploited. The process analyses the business requirements at the outset, and creates a chain of traceability through the strategy and concept, design, implementation, and ongoing manage and measure phases of the lifecycle to ensure that the business mandate is preserved. Framework tools created from practical experience further support the whole methodology. The model is layered, with the top layer being the business requirements definition stage. At each lower layer a new level of abstraction and detail is developed, going through the definition of the conceptual architecture, logical services architecture, physical infrastructure architecture and finally at the lowest layer, the selection of technologies and products (component architecture). The SABSA model itself is generic and can be the starting point for any organisation, but by going through the process of analysis and decision-making implied by its structure, it becomes specific to the enterprise, and is finally highly customised to a unique business model. It becomes in reality the enterprise security architecture, and it is central to the success of a strategic programme of information security management within the organisation 1

The Business View The Architects View The Designers View The Builders View The Tradesmans View The Facilities Managers View

Contextual Security Architecture Conceptual Security Architecture Logical Security Architecture Physical Security Architecture Component Security Architecture Operational Security Architecture

SABSA Model for Security Architecture Development 2 SABSA further organizes the different architectures in a way where the Operational Security Architecture can be used to manage the implementation of the other five architectures as shown below.

1 2

SABSA Overview http://www.sabsa-institute.org/the-sabsa-method/sabsa-overview.aspx http://www.sabsa-institute.org/the-sabsa-method/the-sabsa-model.aspx

Distribution Copy

12 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

SABSA Model for Security Architecture Development 3 The contextual architecture defines security business strategic goals, business vision and the security needs to accomplish the business strategy. The conceptual architecture defines business attributes, the business needs for security. The logical architecture defines the security policy, security requirements, data sharing security needs, security services, privilege profiles, etc. The physical security architecture is concerned with security rules, practice, procedures, and security mechanism. The component architecture includes data structure, security standards and procedures, security products and security tools, processes, protocols, and security tasks timing. Finally the operational architecture is concerned with assurance of operational continuity, risk management, security service management, and security metrics and performance.

Why use SABSA? SABSA offers a business driven approach, risk driven and enterprise-wide solution to security. One important aspect of this model is that it provides best practices and tools used to measure return on investment (ROI) and program performance. It provides traceability of business security requirements as well as a well-defined architectural governance model oriented to business information security. The model is said to be business focus beyond the technical domain.4

3 4

http://www.sabsa-institute.org/the-sabsa-method/the-sabsa-model.aspx http://www.sabsa-institute.org/benefits/role-of-architecture.aspx

Distribution Copy

13 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations The SABSA Institute provides the following benefits summary table: Business Driven A Holistic Approach Fit-for Purpose Measurable Return on Investment Risk-based Cost/Benefit Managing Complexity Providing a Roadmap Simplicity & Clarity Low Cost of Ownership Enabling Business Adding Value Empowering Customers Protecting Relationships Leveraging Trust Assurance Governance Compliance Fast Time to Market Lower Operations Cost Usability Inter-operability Supportability Integration Low cost Development Scalability of Platforms Scalability of Cost Scalability of Security Re-usability Lower Administration Cost

SABSA Benefits Summary table5

VIII. Proposed ESP Framework


The ESP will be implemented in phases following the SABSA life cycle. This life cycle includes six phases during which the architectures for the six different levels of abstractions in the framework are developed. The outcome from the Strategy and Concept phases is the Contextual and Conceptual architectures; the Design phase produces the design of the logical, physical, component and operational architectures. Next, the Implement phase starts followed by the Manage and Measure phases. Each project within the ESP follows this life cycle approach, phases such as implantation, manages and measure may interact to measure the result of components implemented early during the program. In other words, we do not need to wait until the entire program is implemented in order to see the results.

The SABSA Life Cycle 6


5 6

http://www.sabsa-institute.org/benefits/benefits-summary.aspx http://www.sabsa-institute.org/the-sabsa-method/sabsa-lifecycle.aspx.

Distribution Copy

14 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations Five of the architectures, contextual, conceptual, logical, and physical and components produce deliverables that are managed by the operational architecture. The management, administration and operations are known as the SABSA Framework for Security Service Management and it is the deliverable provided by the operations architecture. The matrix below depicts an example of the framework. The deliverables in the example below do not necessarily correspond to NCI-ESP, specific deliverables for the ESP program will be defined as part of the development of the framework.

The SABSA Framework for Security Service Management7 1. Architectures Deliverable The following list describes the deliverables expected from the six different architectures: Contextual Security Architecture Deliverables o Business model, drivers and attributes o Business process model o Organization and relationship model o Time dependencies model o Business risk model

http://www.sabsa-institute.org/the-sabsa-method/sabsa-ssm.aspx all rights reserved

Distribution Copy

15 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations Conceptual Security Architecture Deliverables o Business Attributes profile o Control objectives integrated into business risk model o Assessment of current security status o Security domain model o Security related life-times/deadlines o Security entity model and trust framework o Security strategy and architectural layering o Strategy break-out documents Logical Security Architecture Deliverables o Security Policy Architecture o Security Policies o Logical Security Services o Entity schema and privilege profiles o Security domain and associations o Security processing cycle o Security Improvements plan Physical Security Architecture Deliverables o Business model updated with security data o Security Rules, Practices and Procedures o Security Mechanism o Users, applications and interfaces for security (tools) o Platforms and network infrastructure (lay-out diagrams o System inventory and classifications o Platform and network capacity plan and resilience model (ISCP, DRP, etc.) o Security control structure Component Security Architecture Deliverables o Detailed security data structures o Security standards o Security products and tools o Identities functions, actions, account provisioning, ACLs, etc. o Processes, nodes, addresses and protocols o Security step timing and sequencing (C&A schedules, vulnerability test schedule, upgrades, etc. Operational Security Architecture Deliverables o Framework for Assurance of Operational Continuity o Risk management framework o Security management framework and support framework o Applications and systems management framework o Security management framework for sites, networks and platforms o Framework for managing the security operations schedule

Distribution Copy

16 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations 2. Security Architecture Diagrams The following is a series of diagrams depicting the six architectures corresponding to the security infrastructure. These diagrams are the roadmap to the full implementation of the security program. Diagram Legends: The following section explains the legends used in the diagram below, and provides a brief explanation on how to interpret the diagrams.
analysis Co...

6&1

Indicates input or output from a security related activity. The number in the symbol identifies the source of input from previous diagram and identifies the target on the next diagram; this symbol is also referred to as off-page connector in the context of this document.
analy...

This is an on-page connector symbol and indicates the local reference to an activity on the current diagram.
analysis Conceptual Security Architecture

Synthesize Control Obj ectiv es (Deriv e control obj ectiv es from business Risk model and Business Attributes profile

A security activity resulting in an instruction, standard, procedure or policy document.

Distribution Copy

17 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations


analysis Conceptua...

Controll Objectives notes Integrated into business risk model

A standard, procedure, or policy documentation resulting from a security activity. This symbol contains an attached document when viewed in its original form.

The outputs of one diagram are used as input to different activities on the next diagram providing a transition from one level of abstraction to the next.

a. Contextual Architecture
The contextual architecture below describes the business context to the security program including business inputs that are the fundamental drivers of the security requirements implemented in this program.

Distribution Copy

18 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations


analysis ESP Contextual Architecture Name: Author: Version: Creat ed: Updat ed: ESP Contextual Architecture cabralbj 1.0 1/11/2006 12:00:00 AM 11/24/2009 5:09:24 PM 0

off-page profile Current State

Requirements Business Requirements

0 on-pag e

notes Business Strategy, Drivers, Goals and Objectives Critical success factors, Motivations and Risks Business Processes and Functions Business People and Organization Business Locations and Time Dependencies Budgtes, Technical isses and Other constrains

Working Documents

Contextual Security Arquitecture Business Vision & Mision Business Attributes informs notes Goals, Strategies, and related documents

notes NCI-CBIIT Security Assessment document attached Gather, assess and analize current business state in terms of: Technology infrastructure Service and System management Security policy and practices Management processes

on-page 1 off-page

Description Business Description Business Architecture off-page notes Describe key business drivers using business attributes in terms of: Business Strategy, Related Assets, Business Goals and Objectives informs 0 Requirements Other Requirements notes Business Drivers and Attributes

informs Business Process Model 'Governance" 2 off-page

notes Assess collade and analyse to create output documents

Organization and Relationship Model Domain Model

off-page

Business T hreat s

informs

Time Dependencies Model

5 off-page

Security Assessment (2008)

Analyze Business Risk s Business Risk Model

profile Analyze

notes Analyze Business Risks (part 1) Assets business attributes Assets Threats using treats database impact from business knowledge

off-page 6

notes Analize Business risks (part 2) (Technical Assessment 2008) Technical vulnerabilities Procedural vulnerabilities

off-page 7

Based on SABSA(r) Framework. www.sabsa.org

NCI Enterprise Security Program Contextual Architecture


Distribution Copy

19 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

b. Conceptual Architecture
The conceptual diagram below, describes the business attributes, the control objectives, the assessment of the current security status, resulting in a business risk model for which security controls are implemented to mitigate or eliminate business risks.
analysis Conceptual Security Architecture

6&1

Define business attributes profile Select business attributes (Mapped to Business Driv ers)

Business Attributes

Conceptual Security Architecture

6,7,8

Business Attributes Profile

trace 9

Controll Objectives Synthesize Control Obj ectiv es (Deriv e control obj ectiv es from business Risk model and Business Attributes profile 9 notes Integrated into business risk model 10 10

trace

Assess current state of security against BRM and control obj ectiv es

Assessment of c urrent securit y stat us

trace 11

11

10

Synthesize Conceptual Domain Model

Security Domain Model

trace

12

Synthesize Conceptual Time Model

Security Related Life-time and deadlines

trace

13

2 3 Synthesize Trust Model (entities external and internal) Trust relationship

Security entity model and trust framework

14 trace

Synthesize Maj or security strategies mapped to controll obj ectiv es and to business attributes profile

Security Strategies and architectural layering

15 trace

9 10

11

Describe each maj or security strategy

Individual Strategies Break-out

trace

16

Get Sign-off and Buy-in to conceptual Security Architecture

NCI Enterprise Security Program Conceptual Architecture


Distribution Copy

20 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

c. NCI Enterprise Security Program Logical Architecture


The logical architecture describes activities related to security policy architecture, a description of the logical security services, security processing cycle, security improvement plan and other logical activities driven by the conceptual architecture outputs.
analysis Logical Security Architecture Logical Security Architecture

Business Information Architecture

Rev iew Business Information Architecture

Define Security Policy Architecture

Security Policy Architecture

trace 17

17

11 17 Security Services Dat abase

Perform Policy Gap Analysis

Define Security Policy

Security Policies (Thin books )

trace 18

18

10 15 18 16 Define Security Serv ices based on policies, strategy and control obj ectiv es

Logical Security Servic es

trace 19

19

14

Define Entity Schema & Priv ilage Profile

Entity Schema & Privilage Profile

trace

12

Define Security Domain and Associations

Security Domain & Association

trace

13

Define Security Processing Cycle

Security Processing Cycle

trace

11 19

Perform Serv ice Gap Analysis from current status assessment

Define Improv ement Proj ects

Security Improvements trace

Get sign-off and buying to improv ement proj ects

Based on SABSA(r) Framework. www.sabsa.org

NCI Enterprise Security Program Logical Architecture

Distribution Copy

21 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

d. NCI Enterprise Security Program Physical Architecture


The following diagram depicts the physical architecture of the security program, it includes activities related to business model informed by the security data, and security rules, practices and procedures. It also includes platforms and network infrastructure, system inventories and classification among other activities.
analysis Physical Security Architecture Physical Security Architecture Rev iew Business Data Model

Business Dat a Model

Define Security Data

Business Dat a Model/Data Security Model

trace 20 20

17 Define Security Rules, Practices and Procedures 18

Security Rules, Practices and Procedures

trace

Security Mechanism Dat abase 15 16 20 18 19

Define Security Mechanism

Security Mechanism trace

Define application users community and security interface

Users, Applications, user interf aces for security

trace

Define Platform and Netw ork Infrastructure 19

Platform and network infrastructure (Lay-out )

21 trace

Define Capacity and resiliance requirements

Platforms, network and infrastructure (Capacity and Resilians Model)

trace

Define Control Structure Execution

Control Structure Execution

trace

Based on SABSA(r) Framework. www.sabsa.org

NCI Security Program Physical Architecture

Distribution Copy

22 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

e. NCI Enterprise Security Program Component Architecture


The component architecture describes the tools to be utilized in the implementation of security requirements. This diagram includes activities related to detailed security data structure, security standards, security products and tools, functions, actions, account provisioning, etc.
analysis Component Security Architecture Component Security Architecture

Data Dictionary

Define Syntax of Security Data Structure

Detailed Security Data Structure

trace

Define Security Standards 20

Security St andards

trace

Product Market Information

Select Security Technology, Products and Tools

Security Products & T ools

trace 22

Define Access rights for user and Application Entities 21

Identities, Functions, Access Control Artifacts

trace

Define Details of Infrastructure

Proc esses, Nodes, A ddress, Protocols

trace

Use business attributes to define Capacity and Resilience

Security Step Timing and Sequencing

trace

Based on SABSA(r) Framework. www.sabsa.org

NCI Enterprise Security Program Component Architecture

Distribution Copy

23 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

f. NCI Enterprise Security Program Operational Architecture


Finally, the operational architecture describes the deliverables for the program including framework for information assurance, risk management framework, security management framework and the framework for managing the security operations schedule.
analysis Operatioonal Security Architecture Operational Security Architecture Dev elop Framew ork for Assurance of Operational Continuity 2 3 4 5 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Dev elop Security Management Framew ork for Sites, Netw orks, and Platforms Security Management Framework for Sites, Networks, and Platforms Inputs t o Operatinal Security Architecture Development Dev elop Security Serv ice Management and Support Framew ork Security Service Management and Support Framework Dev elop Operational Risk Management Framew ork Operational Risk Management Framework Framework for Assurance of Operational Continuity

trace

trace

trace 23

Dev elop Application and Users Management Framew ork

Applications & Users Management Framework

trace

trace

Dev elop Security Operations Schedule

Security Operations Schedule Management

trace

NCI Enterprise Security Program Operation Architecture

The next diagram describes how the different architecture diagrams fit together in the overall Enterprise Security Program.

Distribution Copy

24 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations


act NCI-CBIIT Security Framew ork Ov erv iew

NCI Enterprise Security Program Overview

IX.

ESP Performance Measurement

To measure the effectiveness of the ESP, it is necessary to implement a performance measurement model that will allow management to monitor progress and to measure the degree at which the program is meeting its purpose in alignment with the business strategy. The program utilizes a model derived from ISO177799 Security Maturity Model in combination with SABSA Maturity Model and CoBIT 4.1 Maturity Model. The model utilizes the business attributes identified in the business vision and mission and strategic plan and determines to which level the different security areas in the program are meeting the business requirements. The following section provides a table depicting the security categories and business attributes and the different levels in the maturity model. Later in the program, a security management dashboard will be developed along with other measuring tools to maintain stakeholders informed about the performance of the overall program.

Distribution Copy

25 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

NCI ESP Maturity Model Categories Categories Elements Items Covered Measured
User Attributes 10 Accessible, accurate, consistent, duty segregated, timely, usable, supported, informed, security aware Automated, change-managed, cost-effective, maintainable, measured, supportable, controlled Continuous, available, inter-operable, federated, monitored, recoverable, detectable Access-controlled, accountable, auditable, authenticated, authorized, monitored, flexiblysecured, integrity assured, non-reputable, owned, private, trustworthy Compliant, liability-managed, legal, resolvable, time-bound, enforceable Architecturally open, scalable, inter-operable, simple, standards-compliant, traceable, upgradable Business-enabled, competent, credible, enabling time-to-market, governable, reputable, reusable, providing ROI

Management Attributes

Operational Attributes Risk Management Attributes

5 12

Legal and Regulatory Attributes Technical Attributes

6 7

Strategic Attributes

NCI-CBIIT ESP Maturity Model Categories

Distribution Copy

26 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations Maturity Levels Level Title Description 0 Non-existent Complete lack of any recognizable process, organization is unaware of the issue 1 Initial There is evidence that the organization recognize that issues exist and need to be addressed. No standardized process, but ad-hoc and reactive approaches. The overall approach to security management is disorganized 2 Repeatable Processes are developed so that different people performing a task can follow similar procedures. There is no formal training or communication of standard procedures and responsibility is left to the individual. High reliance on the knowledge of single individuals. 3 Defined Procedures are standardized, documented and communicated through training. Left to individuals to implement and deviation is not monitored; procedures are the formalization of existing practices. 4 Managed It is possible to monitor compliance with procedures and to take action where processes are not working effectively. Processes are under constant improvement, automated tools are used in a limited way. 5 Optimized Processes are refined to a level of best practices based on the results of continuous improvement and maturity modeling. Automated processes and tools are in use to improve quality. The enterprise quickly and effectively adapts to changes in the environment (internal and external). NCI-CBIIT ESP Maturity Levels

Other NCI-CBIIT Enterprise Security Program Participants NCI Facilitator for the caBIG DSIC Workspace. Currently the CLO also functions in this role. The DSIC WS Facilitator has responsibility within CBIIT for developing the Data Sharing and Security Framework (DSSF) for caBIG/caGrid. The DSSF is a set of tools that facilitate addressing obstacles to data sharing such a regulatory, ethical, proprietary or sponsored research obstacles. The DSSF also includes policy and guidance tools, including the security and privacy policies governing the caGrid, some of which are being developed under this program.

Enterprise Composite Architecture Team (E-CAT). The E-CAT advises the C Team of CBIIT leadership on technical issues.

Distribution Copy

27 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

X. Additional Stakeholders
a. NCI Chief X Officers: The NCI C Team, listed individually above, is critical to the success of the ESP. Team members individually and collectively share responsibilities for the elements of the full security program for NCI and for caGrid. NCI CBIIT hosts and operates the core infrastructure services of caGrid and is a part of the NIH and HHS, so policies and implementation approaches must be coordinated not only within CBIIT but must align with other security programs. Department of Health and Human Services: The Department has authority in the area of rules development and interpretation of capstone policies, specifically, HIPAA (both the Privacy Rule and the Security Rule), HHS Common Rule as well as security implementing procedures in HHS Secure One program and in HHS implementing guidance for the Privacy Act and other mandates. Note too that the FDA, as part of HHS, issues regulations that cover the conduct of clinical trials of most devices and drugs. b. Office of the National Coordinator for Health IT (ONC): ONC is charged with coordinating health IT infrastructure across the federal government, as well as creating a Nationwide Health Information Network (NHIN). As caGrid has established connectivity to the test NHIN infrastructure, the caBIG security program may serve to inform the NHIN program as a model in some respects. c. National Institute of Standards and Technology (NIST): NIST is charged with providing standards for federal information technology systems under the Federal Information Security Management Act (FISMA) of 2002. NIST has also developed standards focused on Role-Based Access Control (RBAC) that will inform any authorization service developed for caGrid. d. caBIG User Community: This community includes the direct users of caGrids data and analytical services, the stakeholders in and outside of the users institutions who have an interest in securing access to health information including patients, and those participating in the evolving BIG Health Consortium. These are the customers or clients of caGrid services, including security services whose trust in the integrity of the controls in and around the services is essential in order to leverage the promise of the caBIG and BIG Health visions to enable collaborative research and the vision of personalized medicine. e. caBIG Workspaces: For purposes of describing stakeholders, the community is represented both directly and also by the virtual Workspaces into which the caBIG community is organized. Two key workspaces for purposes of the security program include the Data Sharing and Intellectual Capital Workspace (DSIC) and the Architectural Workspace though the domain workspaces for the Clinical Sciences and the Life Sciences represent the application users and developers of application requirements. Supporting all of the workspaces and the community at large are the Knowledge Centers. For security-related
Distribution Copy

28 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations interests, the two key KC stakeholders are the DSIC KC and the caGrid KC. They are charged respectively with mentoring and support to the community respectively in security policy and caGrid technical implementation issues. f. Health Level 7 (HL7): ANSI-certified standards development organization (SDO) active in the area of health data standards. g. Other standards development organizations (SDOs): The NCI Enterprise Security Program will examine and leverage the work of other standards in place today or emerging as they apply to the security construct areas. There may be emerging standards in the clinical research area emanating from the recently formed ANSI Clinical Research Electronic Health Records workgroup or from the HHS ONC activities related to the NHIN that will be examined for applicability as they become available.

XI.

Credits

SABSA is a registered trademark of SABSA Limited. SABSA Limited, 18 Braemore Road, Hove, East Sussex, BN3 4HB. U.K. http://www.sabsa-institute.org/about.aspx. Any material bearing the SABSA trademark has been used with written permission from SABSA Limited with the understanding that proper credit is given and trading marks are maintained. caBIG is a trademark of the National Cancer Center, Center for Biomedical Informatics and Information Technology.

Distribution Copy

29 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

XII. Appendices
Appendix A The chart below is a proposed administrative organization of the NCI Enterprise Security Program.

Distribution Copy

30 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

Appendix B

The SABSA Framework for Security Service Management8

http://www.sabsa-institute.org/the-sabsa-method/sabsa-ssm.aspx all rights reserved

Distribution Copy

31 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations Appendix C caBIG Security Services Concept of Operation The concept of operations below pertains to the caBIG Security Framework or Grid Security Infrastructure; it defines security from a Service Oriented Architecture perspective following ECCF. 1. Vision

The vision of caBIG Security Framework (CSF) is to: Provide enterprise architecture and a risk based systematic approach to integrate adequate security into the caBIG community to protect caBIG assets from threats to privacy, confidentiality, integrity and availability. Enterprise Architecture Approach CSF will align with the NCIs Enterprise Architecture. It will include the approach to develop security artifacts for each architecture layer in the NCI Enterprise Architecture and ensure security is integrated throughout the system development lifecycle (SDLC). Risk Based Approach Any item of value to the organization is considered an asset, including: data, information exchanged through or stored in NCI-hosted systems and applications, some of which are considered protected health information (PHI), personally identifiable information (PII), and intellectual property rights, as well as the supporting infrastructure. Employing a risk based approach will ensure that adequate security is in place for assets of various sensitivities. Integrating security into each architecture layers provides traceability on what risks each security artifact mitigates, and a holistic view of the overall enterprise security posture. A Systematic Approach A systematic approach provides a consistent and manageable effort in integrating security into the overall process and project. It will provide a baseline level of assurance and is the foundation to build a Trust Fabric. In this regard, the CSF can be viewed as a governance framework for integrating security. The CSF is part of the overall NCIs Enterprise Security Program (ESP). One goal of the CSF is to ensure security requirements from NCI ESP are interpreted consistently and applied systematically.

Distribution Copy

32 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

2.

Mission

To achieve the vision, the mission of the NCI caBIG Security Framework is to: Provide a process of creating security artifacts in each enterprise architecture layer Provide a process of aligning security artifacts throughout the NCI system development life cycle Integrate the CSF with the NCI Enterprise Security Program and ensure proper security requirements are represented in each architecture layer Provide Security as a Service (SaaS) to ensure consistent application of security across the caBIG community Objectives

3.

The objective of this initiative is to develop a caBIG Security Framework. The programmatic objectives are: Define security integration points to each enterprise architecture layer and throughout the system development lifecycle. Security integration will not exist alone and efforts will need to take place when the system is going through each lifecycle stage and at different architecture layers. The CSF will need to define where the integration points are as well as the integration process. Define enterprise level Security Services based on caBIG community requirements and infrastructure. The initial task will be to define specific attributes to identify candidate security services and to create a formal consent based process to require when evaluating whether a candidate security service is an enterprise level security service. Define integration points between the CSF and Enterprise Security Program (ESP). ESP will contain guiding principles and policies that caBIG community will follow. The CSF will specify security requirements from the ESP in each architecture layer and throughout the system development lifecycle, and assist caBIG community in achieving compliance with the ESP. Define the Security as Service architecture to implement the CSF.

Distribution Copy

33 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

4.

The caBIG Security Framework Overview

The caBIG Security Framework is an integral part of the NCI-CBIIT Enterprise Security Program. As overarching security program NCI-CBIIT ESP uses the Sherwood Applied Business Security Architecture (SABSA9) which is similar and compliant with (SAEAF)10, but it is specific to a security oriented approach. The architecture layers of NCI CSF are illustrated in the following figure.

Figure: Integrated SABSA Enterprise Security Framework Architecture Model The contextual architecture defines security business strategic goals, business vision and the security needs to accomplish the business strategy. The conceptual architecture defines business attributes, the business needs for security. The logical architecture defines the security policy, security requirements, data sharing security needs, security services, privilege profiles, etc. The physical security architecture is concerned with security rules, practice, procedures, and security mechanism. The logical architecture defines the security policy, security requirements, data sharing security needs, security services, privilege profiles, etc.

10

http://www.sabsa.org/ http://wiki.hl7.org/index.php?title=SAEAF_Document

Distribution Copy

34 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations The physical security architecture is concerned with security rules, practice, procedures, and security mechanism. The component architecture includes data structure, security standards and procedures, security products and security tools, processes, protocols, and security tasks timing.

Finally the operational architecture is concerned with assurance of operational continuity, risk management, security service management, and security metrics and performance. The caBIG Security Framework falls into the conceptual and logical architectures of the overarching SABSA framework. caBIG Current Security Infrastructure The existing security framework for caBIG includes a stand-alone suite of services and tools used to provide authentication, authorization and federation capabilities to the grid. This set of tools is referred to as the Grid Authentication and Authorization with Reliability Distributed Services (GAARDS) and is depicted in the following figure.

The goal of the caBIG Security Framework is to develop a SOA based security infrastructure that would most likely expand the existing GAARDS infrastructure to provide the level of trust in a reusable, integrated and loose coupling, and interoperable manner. Initiatives 1: Security Policies

Distribution Copy

35 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations The caBIG Security Framework envisions creating a comprehensive set of security policies and guidelines. These policies and guidelines would not only define the operations of the caBIG Security infrastructure but also provide an overall governance model for the caBIG Security Framework. These policies will be developed to be fully compliant with caBIGs Data Sharing Framework and will help enforce it. The following two security policy documents are being developed as part of this initiative caBIG Security Policy Statement for caGrid (the Thin Book) Describes the NIH, NCI and federal-wide policies that govern the provision and use of the caGrid infrastructure specifically for users of the caGrid infrastructure. Serves as the outward facing description of the NCI IT security policy for users of caGrid. caBIG Security Policy for caGrid Handbook and Toolkit (or the Thick Book), an implementation guidance document that provides further detail to the caGrid policies and that functions as a how to manual for caGrid service providers and users.

Initiative 2: Security as Services As part of the overall NCI Enterprise Security Program, CSF refers mainly to the security of the caGrid infrastructure. It is based on a Service Oriented approach. It references the guidelines for security as services provided by the Privacy Access and Security Services (PASS) model, which is a joint project between the HL7-SOA and HL7-Security technical committees. Modeling Security as Services has the following benefits: Provide for a higher level of assurance by enforcing consistent application of security across the caBIG community Shorten the system development lifecycle by abstracting the security component of an application or service and provide the security as an independent and reusable capability Increase interoperability and allow an easier to maintain and keep current scalable security architecture Improve alignment with other services provided through the enterprise Service Oriented Architecture

Security as Services refers to the delivery of caGrid infrastructure components, such as authentication, encryption, audit, and access control in a service-oriented fashion in a distributed environment. PASS provides a relatively easy to follow approach that is compliant SOA and the Reference Model for Open and Distributed Processing (RM-ODP) framework. Following PASS and
Distribution Copy

36 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations ECCF guidelines, the caBIG Enterprise Security Framework defines security in terms of the five viewpoints of the RM-ODP model as shown below.
Enterprise Security Specification Stack Conceptual Enterprise/Busines s Viewpoint
Conformance statements business context: FISP, FISMA, HIPAA, NIST, OMB, etc. (thin book) Enterprise Security Governance (constrains) Co-ops, DSSF, ECCF, BCP, DRP Process/Procedures (C&A), Risk Assessment, PIA, DRP, BCP, SDLC-C&A,

Information Viewpoint
Domain analysis Information Security model: Privacy, confidentiality, integrity, availability Enterprise Security Data model, system model, access model. Infrastructure model ESP Security Framework

Computational Viewpoint
Collaboration analysis: Security Specifications (Thick Book)

Engineering Viewpoint
Infrastructure capabilities/constrain s

Logical (PIM)

Security collaboration types: functional, participation, design by contract Collaboration: contracts execution , security transforms, contract administration

Existing/Inherited or new security models, frameworks, infrastructure, etc. Security Implementation context, security technology binding, deployment

Implementable (PSM)

Technology Viewpoint

Security Conformance Assertions

PASS Representation of Security across RM-ODP viewpoints Some of the driving factors for the caBIG Security services are: caBIG Governance model: What is the responsibility split between caBIG participant controls and caBIG infrastructure including the core services caBIG Infrastructure: How is caBIG federated with other credentials? caBIG Trust Fabric: What constitute a Trust Fabric within the system and among the stakeholders? What are applicable levels of assurance?

caBIG Security Framework Building Blocks This section lists several building blocks for the caBIG Security Framework from industry related efforts. Formal analysis and evaluation processes will need to be conducted to decide whether these building blocks will fit in. Contextual Model One of the primary aims of caBIG Security Framework is to facilitate sharing of data across the community in a secured fashion. It has to flexible and scalable to meet current and future data sharing needs while providing the caBIG Program and participants with appropriate
Distribution Copy

37 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations levels of assurance and control over access to data. CSF uses PASS guidelines to drive compliance with the following security controls. caBIG Data Sharing and Security Framework ( data classification guidelines) Support Office of Management and Budgets E-Authentication Guidelines Be compliant with Federal Information Processing Standards 800-53 Guidelines CSF needs to support security requirements of applications regulated by Federal Information Security Management Act Ensure compliance with all the authentication, access control and encryption requirements set by Health Insurance Portability and Accountability Act (HIPAA) Be compliant with all the auditing and electronic signature requirements set by Code for Federal Regulation (CFR) 21 Part 11 Overall NCI, NIH (and HHS) Security Policy Other Local State or Institutional Policies

Figure 4: caBIG Security Framework Adherence Model Conceptual Model The diagram below provides a conceptual view of the overall caBIG Security Framework. This diagram has been adapted from PASS concept diagram and expanded to include privacy tools, as well as authentication tools.

Distribution Copy

38 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

Distribution Copy

39 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations Logical Model From the conceptual model above, the following candidate services for security could be identified. Security Services collection of services which provides authentication, authorization, encryption and de-identification capabilities o Authentication Services collection of the under lying services which together provide authentication capabilities to the CSF Trust Services helps establish trust between the issuer of the identities and the recipients of the identity Identity Delegation Services used to delegate users identity to other service or users Certificate Authority Services used to issue caBIG wide identity to the user Identity Provider Services used to provision a local user and validate their local credentials o Authorization Services - collection of the under lying services which together cater to the authorization needs within the CSF. These services can be used to enforce different type of Access Control mechanism such as Role Based Access Control or Attribute Based Access Control. Policy Provisioning Services used to provision access policy for individual users or group of users. E.g. These services can be used to provision users Role or Attribute across the enterprise Policy Enforcement Service used to enforce the provisioned access policy in order to restrict access to secured data or functionality. These services will enforce access control locally at the grid service level to check whether the user has the required roles or attributes or not. o De-identification Services removes identifiable information from PII in order to distribute it externally o Encryption Services used to encrypt secured and private data sent over the channel or sign it using digital signatures Data Sharing Services services used to enforce data sharing agreements and policies o Policy Services used to implement and enforce the caBIG policies for data sharing Audit Services used to maintain an audit trail of users data access activities at the grid service level

Distribution Copy

40 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

The notional architecture below describes the candidate services and their interaction. The services are arranged into authentication, authorization, audit and encryption. Each service uses attributes or capabilities that could in term be referred as other services or in a grouping approach.

Figure: Notional caBIG Security Architecture The conceptual architecture shown here, identifies some security service candidates, it is intended for illustration only and does not constitute an exhausted list of security services. A more comprehensive list will be developed as part of the requirements gathering phase for the caBIG Security Architecture.

Distribution Copy

41 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations 5. Stakeholders NCI Chief Officers: The NCI C Team is critical to the success of the ESP. Team members individually and collectively share responsibilities for the elements of the full security program for NCI and for caGrid. NCI CBIIT hosts and operates the core infrastructure services of caGrid and is a part of the NIH and HHS, so policies and implementation approaches must be coordinated not only within CBIIT but must align with other security programs. Department of Health and Human Services: The Department has authority in the area of rules development and interpretation of capstone policies, specifically, HIPAA (both the Privacy Rule and the Security Rule), HHS Common Rule as well as security implementing procedures in HHS Secure One program and in HHS implementing guidance for the Privacy Act and other mandates. Note too that the FDA, as part of HHS, issues regulations that cover the conduct of clinical trials of most devices and drugs. Office of the National Coordinator for Health IT (ONC): ONC is charged with coordinating health IT infrastructure across the federal government, as well as creating a Nationwide Health Information Network (NHIN). As caGrid has established connectivity to the test NHIN infrastructure, the caBIG security program may serve to inform the NHIN program as a model in some respects. caBIG User Community: This community includes the direct users of caGrids data and analytical services, data owners and providers, caGrid system owners, the stakeholders in and outside of the users institutions who have an interest in securing access to health information including patients, and those participating in the evolving BIG Health Consortium. These are the customers or clients of caGrid services, including security services whose trust in the integrity of the controls in and around the services is essential in order to leverage the promise of the caBIG and BIG Health visions to create the Trust Fabric and to enable collaborative research and the vision of personalized medicine to operate in a secure manner.

caBIG Workspaces: For purposes of describing stakeholders, the community is represented both directly and also by the virtual Workspaces into which the caBIG community is organized. Two key workspaces for purposes of the security program include the Data Sharing and Intellectual Capital Workspace (DSIC) and the Architectural Workspace though the domain workspaces for the Clinical Sciences and the Life Sciences represent the application users and developers of application requirements. Supporting all of the workspaces and the community at large are the Knowledge Centers. For security-related interests, the two key KC stakeholders are the DSIC KC and the caGrid KC. They are charged respectively with mentoring and support to the community respectively in security policy and caGrid technical implementation issues.
Distribution Copy

42 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

6.

Alternatives/Constraints/Contracting Approach

The caBIG Security Framework (CSF) is part of the overall NCI-CBIIT Enterprise Security Program (ESP). Some of the activities related to CSF are already under way while others are pending availability of resources. The table below depicts the activities related to CSF and security services. These activities are limited in scope to the conceptual and logical level of the CSF.

7.

Risks and Assumptions

The following list of risks related to this project was identified: Actual project costs could be slightly higher or lower than estimates All level of efforts assume implementation will occur as projected All cost figures assume active participation and timely responses from all groups key to activities success. All projections assume no major changes to business process or requirements where those have already been defined. Policies and plans already drafted and submitted for approval will not have any major changes

8.

Other ESP Activities unrelated to CSF.

As previously explained the CSF is part of the overall NCI-CBIIT Enterprise Security Framework. In the overarching framework, the following activities are scheduled for FY10. Security controls review Design Federated ID and Authorization Management Security Monitoring and Audit Plan Establish Web Security Presence Strategic Communication Security and awareness outreach sessions NCI Security Policies review Network Access control provisioning Develop and incorporate appropriate 3rd party (hosting vendors) security compliance provisions. Develop standard users account management policy and template Develop standard auditing policy. Configuration Management Policies Security Handbook maintenance Complete system inventory across all of NCI. Create database system for system inventory control
Distribution Copy

43 6/8/2010

NCI-CBIIT Enterprise Security Program Concept of Operations

XIII. References
John Sherwood, Andrew Clark and David Lynas. Enterprise Security Architecture: A Business-Driven Approach. CPM Books 2005. David A Chapin and Steven Akridge. How Can Security Be Measured? Information Systems Audit and Control Association. www.isaca.org 2005 International Organization for Standardization (ISO), ISO17799, ISO27001. Control Objectives for Information and related Technology COBIT 4.1. Information Systems Audit and Control Association. www.isaca.org Sherwood Applied Business Security Architecture (SABSA). www.sabsa.org National Institute of Standards and Technology (NIST). www.nist.gov Janis R. Putman. Architecting with RM-ODP. Prentice Hall 2001 Services Aware Enterprise Architecture Framework (SAEAF). HL7 http://wiki.hl7.org/index.php?title=SAEAF_200902_Document

Distribution Copy

44 6/8/2010

You might also like