NCI+Enterprise+Security+Concept+of+Operations 01-14-2010v11 Dist

8/6/2019 NCI+Enterprise+Security+Concept+of+Operations 01-14-2010v11 Dist

1/44

Distribution Copy

1

6/8/2010

NCI-Center for Biomedical Informatics and Information

Technology

Enterprise Security Program

Concept of Operations

January 14, 2010

V.11


2/44

NCI-CBIIT Enterprise Security Program Concept of Operations

Distribution Copy

2

6/8/2010

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


3/44


Distribution Copy

3

6/8/2010

Version Date Comments

V.1.0 March 26, 2009 First draft

V.2.0 April 23, 2009 Content review

V.3.0 July 29, 2009 Content review

V.4.0 August 05, 2009 Content review

V.5.0 August 21, 2009 Content reviewV.6.0 September 18, 2009 Content review

V.7.0 September 23, 2009 Content review

V.8.0 October 05, 2009 Content review

V.9.0 October 27, 2009 Content review

V.10 December 2, 2009 Content review

V.11 Letter of Endorsement Endorsement Letter added

II. Distribution List

Stakeholder Title Interest/Stake

Ken Buetow CBIIT Director Sponsor

George A. Komatsoulis

(acting)

CBIIT CIO/NCI Owner

George A. Komatsoulis CBIIT Deputy Director Contributor

Dwayne Forquer CBIIT Chief of Staff/NCI Advisory

Wendy Patterson CBIIT CLO/NCI Contributor

Charlie Mead CBIIT CTO/NCI/BAH Contributor

Caterina Lasome CBIIT COO/NCI

Marsha Young caBIG Security Policy Project

Manager/BAH

Contributor

Avinash Shanbhag CBIIT Director Engineering Advisory

Eric Williams NCI/CBIIT Infrastructure Manager Advisory

Bruce Woodcock NCI/CBIIT ISSO Advisory

Braulio J. Cabral NCI/CBIIT ESP Coordinator Contributor

NIH community NIH Users

NCI Community NCI Users

CBIIT/caBIG Community CBIIT/caBIG Users


4/44


Distribution Copy

4

6/8/2010

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 itemof value to the organization is considered an asset, including; data, information stored in

NCI-hosted systems and applications, some of which are considered protected healthinformation (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 ESPimplements 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 InformationTechnology (CBIIT) OCIO has program responsibility for the NCI ESP.

The scope of the security program is to plan, promote and coordinate the execution of allsecurity 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 tothe 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, accesscontrol, authentication, Encryption/key management, segregation of duties,

auditing/logging/monitoring/review software security, incident response, changemanagement, system development life cycle and security awareness.


5/44


Distribution Copy

5

6/8/2010

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 NCIcommunity. 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 informationassets 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 notlimited to the policies inherited from NIH Security Plan, policies governing the

caGrid core infrastructure services, the policies and procedures governing the usersof 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 andmemoranda of understanding/agreement with other entities outside of CBIIT.

Guidelines and standards to validate compliance with the policies and technicalimplementation of the trust fabric, as well as compliance with relevant statutes andrules governing federal and non-federal information systems.

The NCI security services infrastructure that implements the policies and theoperational 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 summarizedas; 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.


6/44


Distribution Copy

6

6/8/2010

Communications

SecurityT

rainin

g

ITSecurityParticipation

Outre

ach&

Awareness

Comm

unity

Feedba

ck

Security

Policy andCompliance

DSSF

NIH/NCI

Engineering & Operations

Baseline Security Controls

Enterprise SecurityGovernance

(ConOps)

Business

Information

& Data

Standards,

Guidelines &

Procedures

Hardware

(Servers, OS)

SDLC Security

ECCF

Framework

Middleware

(caGrid, apps)

Physical

Infrastructure

(LAN, Building,

Personnel)

Business Needs

ComplianceFederationScalability

Clarity

Easiness

Busine

ssStra

tegicP

lan

Com

munityN

eeds

FederalSecurityR

egulations

Ente

rpris

eGov

erna

nce

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 softwarearchitecture, Director Quality Control, Director software deployment

Infrastructure Engineering and Operations team responsible for implementing andenforcing 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 thevarious agreements between the NCI and external parties that memorializecommitments to various aspects of the ESP including such documents as Memoranda


7/44


Distribution Copy

7

6/8/2010

of Agreement, caGrid node Host agreements, NCI web services use agreements, inter

NIH agreements, etc.

Office of the Chief Information Officer. Responsible for developing andimplementing 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 thatimplement 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 mandatesfor those elements of the enterprise services that are hosted by NCI-CBIIT and itmust facilitate compliance by users of the services and applications with applicablefederal, state and local laws, regulations, policies and other requirements.

2. Federation: The infrastructure must allow the secure sharing of identity informationbetween trusted participants and federation of authorization decisions by local data

stewards.

3. Scalability: The infrastructure must be capable of scaling up to an arbitrarynumber of users and services with minimal disruptive redesign of the infrastructure.

4. Clarity: The implementation of the infrastructure must provide understandableguidance 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 datasharing 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


8/44


Distribution Copy

8

6/8/2010

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 createa 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 fabricthat 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 andprocedures, 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 individualproviders 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, provideuser templates and checklists, explain automated and non-automated (i.e., executed

off-line) agreements in use and educate NCI users and other stakeholders interestedin 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 andvalidate 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


9/44


Distribution Copy

9

6/8/2010

tasks and ensuring that the security infrastructure supports CBIIT security program

objectives. As discussed in more detail below in Section X (Management of CBIITEnterprise 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 Policyi. Development of procedures and standards for effective

implementation of NCI Information Security Plan.

ii. Development of business level security policies related to CBIIT andcaGrid services, service providers and users.

iii. Development contract/trust agreements for caGrid users

b. Security Engineering and Operationsi. 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 securityguidance, standards, and procedures to implement and validate thesecurity policy. (See caBIG Infrastructure Security Implementation

Model for more details)

c. Security Outreach and Awarenessi. Establish NCI Web Security Presence

ii. Strategic Communications from Program Office/CIO/ISSOiii. 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 informationsecurity requirements for NCI-hosted services. The policy framework for the NCI EnterpriseSecurity 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).


10/44


Distribution Copy

10

6/8/2010

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 whereneeded

2. Identity and Privilege Management policies (Authentication and AuthorizationPolicies)

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 flowfrom the NIH Enterprise Information Security Plan and other laws, regulations andpolicies 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 theoutward facing description of the NCI IT security policy for users of caGrid.

caBIG Security Policy for caGrid Handbook and Toolkit (or the Thick Book), animplementation 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 OperationsThis group of tasks focuses on developing, implementing and deploying the security

infrastructure as informed by the security policies. Specific task areas initially definedinclude:

1. Security Monitoring & Audit Model2. Certification and Accreditation Program Management at the infrastructure (network)

level, systems and applications level.

3.

Compliance Assessment4. Configuration Management and Control5. Contingency planning including:

a. Business impact analysisb. Business Continuity planc. Disaster Recovery plan


11/44


Distribution Copy

11

6/8/2010

d. Security Bridge notification plane. Plan maintenance

6. Design caBIG Infrastructure Security Framework (trust fabric) (See caBIG SecurityInfrastructure Services ConOps Appendix C)

7. Software Development Life Cycle (SDLC) Security frameworkC. 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 caGridKnowledge 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. Establish NCI/caGrid Web Security Presenceb. Strategic Communications from Program Office/CIO/ISSOc. Security Awareness and Outreach Sessionsd. Compliance/Trust Agreement Notifications & Reminders

VII. Operations Governance for NCI-CBIITEnterprise 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 responsibilitiesfor 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 theenterprise-wide security program. The SABSA Institute describes this security framework

as follows:

SABSA is a model and a methodology for developing risk-driven enterpriseinformation security architectures and for delivering security infrastructure solutionsthat support critical business initiatives. The primary characteristic of the SABSA

model is that everything must be derived from an analysis of the business


12/44


Distribution Copy

12

6/8/2010

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 oftraceability through the strategy and concept, design, implementation, and ongoing

manage and measure phases of the lifecycle to ensure that the business mandate ispreserved. Framework tools created from practical experience further support thewhole methodology.

The model is layered, with the top layer being the business requirements definitionstage. 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 itsstructure, it becomes specific to the enterprise, and is finally highly customised to a

unique business model. It becomes in reality the enterprise security architecture, andit is central to the success of a strategic programme of information security

management within the organisation 1

The Business View Contextual Security Architecture

The Architects View Conceptual Security Architecture

The Designers View Logical Security Architecture

The Builders View Physical Security Architecture

The Tradesmans View Component Security ArchitectureThe Facilities Managers View Operational Security Architecture

SABSA Model for Security Architecture Development2

SABSA further organizes the different architectures in a way where the Operational

Security Architecture can be used to manage the implementation of the other fivearchitectures as shown below.

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

2http://www.sabsa-institute.org/the-sabsa-method/the-sabsa-model.aspx


13/44


Distribution Copy

13

6/8/2010

SABSA Model for Security Architecture Development3

The contextual architecture defines security business strategic goals, business visionand 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 operationalcontinuity, risk management, security service management, and security metrics andperformance.

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 usedto 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 thetechnical domain.4

3http://www.sabsa-institute.org/the-sabsa-method/the-sabsa-model.aspx

4http://www.sabsa-institute.org/benefits/role-of-architecture.aspx


14/44


Distribution Copy

14

6/8/2010

The SABSA Institute provides the following benefits summary table:

Business Driven Enabling Business Usability

A Holistic Approach Adding Value Inter-operability

Fit-for Purpose Empowering Customers Supportability

Measurable Protecting Relationships IntegrationReturn on Investment Leveraging Trust Low cost Development

Risk-based Cost/Benefit Assurance Scalability of Platforms

Managing Complexity Governance Scalability of Cost

Providing a Roadmap Compliance Scalability of Security

Simplicity & Clarity Fast Time to Market Re-usability

Low Cost of Ownership Lower Operations Cost 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 thelogical, 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 isimplemented in order to see the results.

The SABSA Life Cycle6

5http://www.sabsa-institute.org/benefits/benefits-summary.aspx

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


15/44


Distribution Copy

15

6/8/2010

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 bedefined as part of the development of the framework.

The SABSA Framework for Security Service Management7

1. Architectures DeliverableThe following list describes the deliverables expected from the six different architectures:

Contextual Security Architecture Deliverableso Business model, drivers and attributeso Business process modelo Organization and relationship modelo Time dependencies modelo Business risk model

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


16/44


Distribution Copy

16

6/8/2010

Conceptual Security Architecture Deliverableso Business Attributes profileo Control objectives integrated into business risk modelo Assessment of current security statuso Security domain modelo

Security related life-times/deadlineso Security entity model and trust frameworko Security strategy and architectural layeringo Strategy break-out documents

Logical Security Architecture Deliverableso Security Policy Architectureo Security Policieso Logical Security Serviceso Entity schema and privilege profileso Security domain and associationso Security processing cycleo

Security Improvements plan Physical Security Architecture Deliverables

o Business model updated with security datao Security Rules, Practices and Procedureso Security Mechanismo Users, applications and interfaces for security (tools)o Platforms and network infrastructure (lay-out diagramso System inventory and classificationso Platform and network capacity plan and resilience model (ISCP, DRP, etc.)o Security control structure

Component Security Architecture Deliverableso Detailed security data structureso Security standardso Security products and toolso Identities functions, actions, account provisioning, ACLs, etc.o Processes, nodes, addresses and protocolso Security step timing and sequencing (C&A schedules, vulnerability test

schedule, upgrades, etc.

Operational Security Architecture Deliverableso Framework for Assurance of Operational Continuityo Risk management frameworko Security management framework and support frameworko Applications and systems management frameworko Security management framework for sites, networks and platformso Framework for managing the security operations schedule


17/44


Distribution Copy

17

6/8/2010

2. Security Architecture DiagramsThe following is a series of diagrams depicting the six architectures corresponding to thesecurity 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 thesymbol 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...

9

This is an on-page connector symbol and indicates the local reference to anactivity on the current diagram.

analysis Conceptual Security Architecture

Synthesize Control Objectiv es (Derivecontrol objectiv es from business Riskmodel and Business Attributes profile

A security activity resulting in an instruction,

standard, procedure or policy document.


18/44


Distribution Copy

18

6/8/2010

analysis Conceptua...

Controll

Objectives

notesIntegrated 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 originalform.

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 programincluding business inputs that are the fundamental drivers of the security requirements

implemented in this program.


19/44


Distribution Copy

19

6/8/2010

analysis ESP Contextual Architecture

Contextual Security Arquitecture

Requirements

Business Requirements

notesBusiness Strategy, Drivers, Goals and Ob jectives

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

DescriptionBusiness Description

notesDescribe key busi ness drivers using business

attributes in terms of: Business Strategy, Rel ated

Assets, Business Goals and Objectives

Analyze

Business Risks

notesAnalyze Business Risks (part 1)

Assets business attributes

Assets Threats using treats database impact from

business knowledge

Requirements

Other Requirements

notesAssess collade and analyse to create output

documents

Working Documents

profile

Current State

notesNCI-CBIIT Security Assessment document

attached

Gather, assess and anali ze current

business state i n terms of:

Technology i nfrastructure

Service and System management

Security policy and practices

Management processes

profile

Analyze

notesAnalize B usiness risks (part 2)

(Technical Assessment 2008 )

Technical vulnerabilities

Procedural vulnerabilities

2

3

5

1

6

7

1

0Business

Process Mode l

'Governance"

Organization

and

Relationship

Model

Time

Dependencies

Model

Business Risk

Model

Business

Architecture

notesBusiness Drivers

and Attributes

Business

Vision & Mi sion

notesGoals,

Strategies, and

related

documents

0

0

1

Name: ESP Contextual Archi tecture

A uth or: ca bra lb j

Ve rsi on : 1.0

Created: 1/11/2006 12:00:00 AM

Updated: 11/24/2009 5:09:24 PM

Business

Attributes

BusinessThreats Security

Assessment

(2008)

8

Domain Model4

Based on SABSA(r) Framework.

www.sabsa.org

informs

informs

off-page

informs

off-page

informs

on-page

off-page

on-page

off-page

off-page

off-page

off-page

off-page

NCI Enterprise Security Program Contextual Architecture


20/44


Distribution Copy

20

6/8/2010

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 Se curity Architecture

Conceptual S ecurity Architecture

Business

Attributes6 & 1

Business

Attributes

Profile

Controll

Objectives

notesIntegrated into

business risk

model

Assessment of c urrent

security status

Security Domain

Model

Security Related

Life-time and

deadlines

Security entity model

and trust framework

Security Strategies

and architectural

layering

Individual Strategies

Break-outDescribe e achmajor security

strategy

Synthesize Major security strategiesmapped to controll objec tives and to

business attributes profile

Synthesize Trust Model (entities e xternaland internal) Trust relationship

Synthesize Conceptual Time Model

Synthesize Conceptual Domain Model

Assess c urrent state of security againstBRM and control objectiv es

Synthesize Control Obje ctives (Deriv econtrol objectives from business Riskmodel and Business Attributes profile

Get Sign-off and Buy-in toconceptual Security

Architecture

Define business attributes profileSelect business attributes (Mapped to

Business Drivers )

6,7,8

9

0

10

4

5

2

3

2

9

10

11

9

9

10

10

11

11

12

13

14

15

16

trace

trace

trace

trace

trace

trace

trace

trace

NCI Enterprise Security Program Conceptual Architecture


21/44


Distribution Copy

21

6/8/2010

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 S ecurity Architecture

Logical Security Architecture

Security Policy

Architecture

Security

Policies (Thin

books)

Logical

Security

Services

Entity Schema

& Privilage

Profile

Security

Domain &

Association

Security

Processing

Cycle

Security

Improvements

Business

Information

Architecture

Review BusinessInformation Architecture

Define Security PolicyArchitecture

Perform Policy GapAnalysis

Define Security Policy

Define Security Servicesbased on policies, strategy

and control objectives

Define Entity Schema &Privilage Profile

Define Security Domainand Associations

Define SecurityProcessing Cycle

Perform Service GapAnalysis from current

status assessment

Define Improve mentProjects

Get sign-off and buying toimprovement projects

17

17

18

18

19

19

11

17

Security

Services

Database

10

15

16

18

14

12

13

11

19


www.sabsa.org

trace

trace

trace

trace

trace

trace

trace

NCI Enterprise Security Program Logical Architecture


22/44


Distribution Copy

22

6/8/2010

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

Business Data

Model/Data Security

Model

Security Rules,

Practices and

Procedures

Security Mechanism

Users, Applicati ons,

user interfaces for

security

Platforms, network and

infrastructure (Capacity

and Resilians Model)

Control Structure

Execution

Business Data

ModelReview Business Data

Model

Define Security Data

Define Security Rules,Practices and Procedures

Define SecurityMechanism

Define Platform and

Network Infrastructure

Define Capacity and

resiliance requirements

Define Control StructureExecution

Platform and network

infrastructure (Lay-out)

Define application users

community and securityinterface

17

18

Security

Mechanism

Database

15

16

18

19

20

19

9

20

20

21

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

trace

trace

trace

trace

trace

trace

trace

NCI Security Program Physical Architecture


23/44


Distribution Copy

23

6/8/2010

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 Sec urity Architecture

Component Security Architecture

Data Dictionary

Product

Market

Information

Define Syntax of SecurityData Structure

Define Security Standards

Selec t Security Technology,Products and Tools

Define Access rights foruser and Application

Entities

Define Details ofInfrastructure

Use business attributes todefine Capacity and

Resilience

20

21

Detailed Se curity

Data Structure

Security

Standards

Security Products

& Tools

Identities,

Functions,

Access Control

Artifacts

Processes,

Nodes, A ddress,

Protocols

Security Step

Timing and

Sequencing


www.sabsa.org

22

trace

trace

trace

trace

trace

trace

NCI Enterprise Security Program Component Architecture


24/44


Distribution Copy

24

6/8/2010

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

Framework for

Assurance o f

Operational Continuity

Operational Risk

Management

Framework

Security Service

Management and

Support Framework

Appli cations & Users

Management

Framework

Security Management

Framework for Sites,

Networks, and

Platforms

Security Operations

Schedule

Management

Deve lop Framew ork for

Assurance of OperationalContinuity

Develop Operational RiskManagement Framework

Develop Security Serv iceManagement and Support

Framework

Dev elop Application andUsers Management

Framework

Deve lop SecurityManagement Framework

for Sites, Networks, andPlatforms

Deve lop SecurityOperations Schedule

2

3

Inputs to

OperatinalSecurity

Architecture

Development

4

5

10

9

11

1213

14

15

16

17

18

19

20

21

22

23

trace

trace

trace

trace

trace

trace

NCI Enterprise Security Program Operation Architecture

The next diagram describes how the different architecture diagrams fit together in the overall

Enterprise Security Program.


25/44


Distribution Copy

25

6/8/2010

act NCI-CBIIT Security Framework Overv iew

NCI Enterprise Security Program Overview

IX. ESP Performance MeasurementTo measure the effectiveness of the ESP, it is necessary to implement a performancemeasurement 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 planand 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.


26/44


Distribution Copy

26

6/8/2010

NCI ESP Maturity Model Categories

Categories Elements

Measured

Items Covered

User Attributes 10 Accessible, accurate, consistent, duty

segregated, timely, usable, supported,informed, security aware

Management Attributes 7 Automated, change-managed, cost-effective,

maintainable, measured, supportable,

controlled

Operational Attributes 5 Continuous, available, inter-operable,federated, monitored, recoverable, detectable

Risk ManagementAttributes

12 Access-controlled, accountable, auditable,authenticated, authorized, monitored, flexibly-

secured, integrity assured, non-reputable,

owned, private, trustworthy

Legal and RegulatoryAttributes

6 Compliant, liability-managed, legal,resolvable, time-bound, enforceable

Technical Attributes 7 Architecturally open, scalable, inter-operable,

simple, standards-compliant, traceable,upgradable

Strategic Attributes 8 Business-enabled, competent, credible,

enabling time-to-market, governable,

reputable, reusable, providing ROI

NCI-CBIIT ESP Maturity Model Categories


27/44


Distribution Copy

27

6/8/2010

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 andreactive 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 orcommunication 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 isnot 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 limitedway.

5 Optimized Processes are refined to a level of best practices based on theresults 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 theenvironment (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 inthis 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 policyand 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 CTeam of CBIIT leadership on technical issues.


28/44


Distribution Copy

28

6/8/2010

X. Additional Stakeholdersa. 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 forcaGrid. NCI CBIIT hosts and operates the core infrastructure services of

caGrid and is a part of the NIH and HHS, so policies and implementationapproaches must be coordinated not only within CBIIT but must align withother 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 implementingprocedures 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 ofmost devices and drugs.

b. Office of the National Coordinator for Health IT (ONC): ONC is chargedwith coordinating health IT infrastructure across the federal government, aswell 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 withproviding standards for federal information technology systems under the

Federal Information Security Management Act (FISMA) of 2002. NIST hasalso 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 ofcaGrids data and analytical services, the stakeholders in and outside of theusers 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 caGridservices, 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 communityis represented both directly and also by the virtual Workspaces into which the

caBIG community is organized. Two key workspaces for purposes of thesecurity 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 andthe community at large are the Knowledge Centers. For security-related


29/44


Distribution Copy

29

6/8/2010

interests, the two key KC stakeholders are the DSIC KC and the caGrid KC.

They are charged respectively with mentoring and support to the communityrespectively 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 EnterpriseSecurity Program will examine and leverage the work of other standards in

place today or emerging as they apply to the security construct areas. Theremay 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 fromSABSA 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.


30/44


Distribution Copy

30

6/8/2010

XII. Appendices

Appendix A

The chart below is a proposed administrative organization of the NCI Enterprise Security

Program.


32/44


Distribution Copy

32

6/8/2010

Appendix C caBIG Security Services Concept of OperationThe 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 arisk basedsystematicapproach to integrate

adequatesecurity into the caBIG community to protect caBIG assets from threats to privacy,

confidentiality, integrity and availability.

Enterprise Architecture ApproachCSF 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 ApproachAny 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 basedapproach 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 ApproachA systematic approach provides a consistent and manageable effort in integrating securityinto 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.


33/44


Distribution Copy

33

6/8/2010

2. MissionTo 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 securityrequirements are represented in each architecture layer

Provide Security as a Service (SaaS) to ensure consistent application of security acrossthe caBIG community

3. ObjectivesThe 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 throughoutthe 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 atdifferent 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 andinfrastructure. The initial task will be to define specific attributes to identify candidatesecurity 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.


34/44


Distribution Copy

34

6/8/2010

4. The caBIG Security Framework OverviewThe caBIG Security Framework is an integral part of the NCI-CBIIT Enterprise Security

Program. As overarching security program NCI-CBIIT ESP uses the Sherwood AppliedBusiness 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 logical architecture defines the security policy, security requirements, data sharingsecurity needs, security services, privilege profiles, etc.

9http://www.sabsa.org/

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


35/44


Distribution Copy

35

6/8/2010


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 setof 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


36/44


Distribution Copy

36

6/8/2010

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 thecaBIG 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, NCIand 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), animplementation 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 securityacross the caBIG community

Shorten the system development lifecycle by abstracting the security component of anapplication or service and provide the security as an independent and reusable

capability

Increase interoperability and allow an easier to maintain and keep current scalablesecurity architecture

Improve alignment with other services provided through the enterprise Service OrientedArchitecture

Security as Services refers to the delivery of caGrid infrastructure components, such asauthentication, 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


37/44


Distribution Copy

37

6/8/2010

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

Enterprise/Busines

s Viewpoint

Information

Viewpoint

Computational

Viewpoint

Engineering

Viewpoint

Conceptual Conformance

statements businesscontext: FISP, FISMA,

HIPAA, NIST, OMB,

etc. (thin book)

Domain analysis

Information Securitymodel:

Privacy,

confidentiality,

integrity, availability

Collaboration

analysis:Security Specifications

(Thick Book)

Infrastructure

capabilities/constrains

Logical (PIM) Enterprise SecurityGovernance

(constrains)

Co-ops, DSSF, ECCF,

BCP, DRP

Enterprise Security

Data model, system

model, access model.

Infrastructure model

Security collaboration

types: functional,

participation, design

by contract

Existing/Inherited or

new security models,

frameworks,

infrastructure, etc.

Implementable

(PSM)

Process/Procedures

(C&A), Risk

Assessment, PIA, DRP,

BCP, SDLC-C&A,

ESP Security

Framework

Collaboration:

contracts execution ,

security transforms,

contract

administration

Security

Implementation

context, security

technology binding,

deployment

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 participantcontrols 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 acrossthe 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

Technology

Viewpoint

Security Conformance Assertions


38/44


Distribution Copy

38

6/8/2010

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 BudgetsE-Authentication Guidelines Be compliant with Federal Information Processing Standards 800-53 Guidelines CSFneeds to support security requirements of applications regulated by Federal

Information Security Management Act

Ensure compliance with all the authentication, access control and encryptionrequirements set by Health Insurance Portability and Accountability Act (HIPAA)

Be compliant with all the auditing and electronic signature requirements set by Codefor 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.


39/44


Distribution Copy

39

6/8/2010


40/44


Distribution Copy

40

6/8/2010

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 togetherprovide authentication capabilities to the CSF

Trust Services helps establish trust between the issuer of the identitiesand the recipients of the identity

Identity Delegation Services used to delegate users identity to otherservice or users

Certificate Authority Services used to issue caBIG wide identity to theuser

Identity Provider Services used to provision a local user and validatetheir local credentials

o Authorization Services - collection of the under lying services which togethercater to the authorization needs within the CSF. These services can be used toenforce 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 forindividual users or group of users. E.g. These services can be used to

provision users Role or Attribute across the enterprise

Policy EnforcementService used to enforce the provisioned accesspolicy 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 thechannel or sign it using digital signatures

Data Sharing Services services used to enforce data sharing agreements and policieso 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 thegrid service level


41/44


Distribution Copy

41

6/8/2010

The notional architecture below describes the candidate services and their interaction. Theservices 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 groupingapproach.

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 forthe caBIG Security Architecture.


42/44


Distribution Copy

42

6/8/2010

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 andimplementation 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 withcoordinating health IT infrastructure across the federal government, as well as creating aNationwide Health Information Network (NHIN). As caGrid has establishedconnectivity 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 dataand 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 evolvingBIG 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 theservices is essential in order to leverage the promise of the caBIG and BIG Healthvisions 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 isrepresented both directly and also by the virtual Workspaces into which the caBIG

community is organized. Two key workspaces for purposes of the security programinclude 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 applicationrequirements. Supporting all of the workspaces and the community at large are theKnowledge 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 technicalimplementation issues.


43/44


Distribution Copy

43

6/8/2010

6. Alternatives/Constraints/Contracting ApproachThe 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 arepending availability of resources. The table below depicts the activities related to CSF andsecurity services. These activities are limited in scope to the conceptual and logical level of

the CSF.

7. Risks and AssumptionsThe 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 SecurityFramework. 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


44/44


XIII. References

John Sherwood, Andrew Clark and David Lynas. Enterprise Security Architecture: ABusiness-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). HL7http://wiki.hl7.org/index.php?title=SAEAF_200902_Document

NCI+Enterprise+Security+Concept+of+Operations 01-14-2010v11 Dist

Documents

Transcript of NCI+Enterprise+Security+Concept+of+Operations 01-14-2010v11 Dist