ASTM E2595-07(2013)
(Guide)Standard Guide for Privilege Management Infrastructure (Withdrawn 2017)
Standard Guide for Privilege Management Infrastructure (Withdrawn 2017)
SIGNIFICANCE AND USE
4.1 Motivation for the PMI comes from several organizational and application areas. For example:
4.1.1 Supporting a distributed heterogeneous application architecture with a homogeneous distributed security infrastructure leveraged across the enterprise; providing user and service identities and propagation; and providing a common, consistent security authorization and access control infrastructure.
4.1.2 Providing mechanisms to describe and enforce enterprise security policy systematically throughout the organization for consistency, maintenance, and ease of modification and to demonstrate compliance to applicable regulation and law.
4.1.3 Providing support for distributed/service-oriented architectures in which enterprise-wide services and authoritative sources are protected by providing security services that themselves are also distributed using common interfaces and communication protocols.
4.1.4 Providing “economies of scale” where it is desired to change the approach of individually managing the configuration of each point of enforcement to one that establishes a consolidated view of the safeguards in effect throughout the enterprise.
4.1.5 Providing centralized control, management, and visibility to security policy across the enterprise and when connecting to other organizations. This allows for additional key features such as delegated administration, centralized policy analysis, and consolidated reporting.
4.1.6 Providing a distributed computing security architecture allowing for synchronized security services that are efficiently maintained across the enterprise while also allowing for centralized policy control and distributed policy decision-making/enforcement. Ensuring proper security controls are enacted for each service and when used in combination.
4.1.7 Provisioning incremental updates to policy and configuration data simultaneously across all distributed decision/enforcement points. Establishing and enforcing new policies no...
SCOPE
1.1 This guide defines interoperable mechanisms to manage privileges in a distributed environment. This guide is oriented towards support of a distributed or service-oriented architecture (SOA) in which security services are themselves distributed and applications are consumers of distributed services.
1.2 This guide incorporates privilege management mechanisms alluded to in a number of existing standards (for example, Guide E1986 and Specification E2084). The privilege mechanisms in this guide support policy-based access control (including role-, entity-, and contextual-based access control) including the application of policy constraints, patient-requested restrictions, and delegation. Finally, this guide supports hierarchical, enterprise-wide privilege management.
1.3 The mechanisms defined in this guide may be used to support a privilege management infrastructure (PMI) using existing public key infrastructure (PKI) technology.
1.4 This guide does not specifically support mechanisms based on secret-key cryptography. Mechanisms involving privilege credentials are specified in ISO 9594-8:2000 (attribute certificates) and Organization for the Advancement of Structured Information Standards (OASIS) Security Assertion Markup Language (SAML) (attribute assertions); however, this guide does not mandate or assume the use of such standards.
1.5 Many current systems require only local privilege management functionality (on a single computer system). Such systems frequently use proprietary mechanisms. This guide does not address this type of functionality; rather, it addresses an environment in which privileges and capabilities (authorizations) shall be managed between computer systems across the enterprise and with business partners.
1.6 This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility of the user of this standard to establish appropr...
General Information
Relations
Standards Content (Sample)
NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
Designation: E2595 − 07 (Reapproved 2013) An American National Standard
Standard Guide for
Privilege Management Infrastructure
This standard is issued under the fixed designation E2595; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
INTRODUCTION
This guide arises from the ongoing development and implementation of privilege management
infrastructures (PMIs) within the healthcare environment. The healthcare environment supported by
this guide is enterprise-wide and extends beyond traditional borders to include external providers,
suppliers, and other healthcare partners. This guide supports privilege management within distributed
computing as well as service-oriented architecture environments. This guide supports a distributed
security environment in which security is also a distributed service.
Thehealthcaresectoriscontinuallyimprovingthedeliveryofcarebyleveragingtechnicaladvances
in computer-based applications. Health professionals are increasingly accessing multiple applications
to schedule, diagnose, and administer patient care. These disparate applications are typically
connected to a common network infrastructure that typically supports patient, business, and
nonbusiness services, communications, and protocols. Because increased access is made possible
through a common network infrastructure, secure access to these distributed, and often loosely
coupled applications, is even more important than when these applications were accessed as
stand-alone devices.
Secure access to legacy computer-based healthcare applications typically involves authentication of
the user to the application using single-factor identification, such as a password, or multifactor
identification, such as a password combined with a token or biometric devices. After authentication,
the application determines the authority that user may have to use aspects of the application.
Determining the level of authority a user has is typically done, if at all, by each application. The
application may restrict operations (such as read, write, modify, or delete) to an application-specific
group or role affiliation. Authenticated users are frequently associated with groups or roles using a
local database or flat file under the control of an application administrator.
The use of a local mechanism for authorization creates a patchwork of approaches difficult to
administer centrally across the breadth of a healthcare enterprise. That is, the software logic
determiningauthorizationisdistinctivetoeachapplication.Insomecases,applicationscanbeadapted
to use a network database that contains a trusted source of name-value pairs. This information allows
applications to determine the user’s group or role affiliation.This approach permits centralized control
over a shared user base. However, the resulting granularity of control over user authorization is coarse
and shall be interpreted by each application specialist. Granularity of user authority can only be
improved by increasing the number of application-specific groups or roles in the shared database.
Storinginformationspecifictoeachapplicationcausesexponentialgrowthofrolesperuserandresults
in provisioning difficulties. The better solution is to associate industry standard permissions to users.
Each application can examine the permissions listed for a user and determine their level of
authorization regardless of their group affiliation within the healthcare organization.
The resulting system is a PMI. By the nature of the problem, the privileges shall be defined in an
industry standard way. This guide will discuss various aspects of identifying a PMI standard to
vendors providing healthcare applications to the contemporary healthcare enterprise.
1. Scope ture (SOA) in which security services are themselves distrib-
uted and applications are consumers of distributed services.
1.1 This guide defines interoperable mechanisms to manage
privileges in a distributed environment. This guide is oriented 1.2 This guide incorporates privilege management mecha-
towards support of a distributed or service-oriented architec- nisms alluded to in a number of existing standards (for
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
E2595 − 07 (2013)
example,GuideE1986andSpecificationE2084).Theprivilege 2.3 HL7 Standard:
mechanisms in this guide support policy-based access control Health Level 7 Context Management “CCOW” (Clinical
(including role-, entity-, and contextual-based access control) Context Object Workgroup) Standard, Version 1.5
including the application of policy constraints, patient-
2.4 IETF Standards:
requested restrictions, and delegation. Finally, this guide sup-
RFC 3198 Terminology for Policy-Based Management
ports hierarchical, enterprise-wide privilege management.
RFC 3280 Internet X.509 Public Key Infrastructure Certifi-
cate and Certificate Revocation List (CRL) Profile
1.3 The mechanisms defined in this guide may be used to
support a privilege management infrastructure (PMI) using RFC 3881 Security Audit and Access Accountability Mes-
sage XML Data Definitions for Healthcare Applications
existing public key infrastructure (PKI) technology.
2.5 ISO Standards:
1.4 This guide does not specifically support mechanisms
ISO 9594-8 The Directory: Public-Key and Attribute Cer-
based on secret-key cryptography. Mechanisms involving
tificate Frameworks; also available as ITU-T X.509: 2000
privilege credentials are specified in ISO 9594-8:2000 (attri-
ISO 10181-3-00 Security Frameworks for Open Systems:
bute certificates) and Organization for the Advancement of
Access Control Framework; also available as ITU-T
Structured Information Standards (OASIS) Security Assertion
X.812: 1995
MarkupLanguage(SAML)(attributeassertions);however,this
ISO/TS 21298 Functional and Structure Roles
guide does not mandate or assume the use of such standards.
ISO/TS 22600-2:2006 Health Informatics—Privilege Man-
1.5 Many current systems require only local privilege man-
agement and Access Control—Part 2: Formal Models
agement functionality (on a single computer system). Such
2.6 OASIS Standards:
systems frequently use proprietary mechanisms. This guide
Security Assertion Markup Language (SAML) v2.0
does not address this type of functionality; rather, it addresses
SAML 2.0 Profile of XACML
an environment in which privileges and capabilities (authori-
Security Provisioning Markup Language (SPML) v2.0,
zations) shall be managed between computer systems across
(OASIS)
the enterprise and with business partners.
Web Services Business Process Execution Language (WS-
1.6 This standard does not purport to address all of the
BPEL v2)
safety concerns, if any, associated with its use. It is the
WS-Trust (WS-Trust 1.3)
responsibility of the user of this standard to establish appro-
eXtensible Access Control Markup Language (XACML)
priate safety and health practices and determine the applica-
v2.0
bility of regulatory limitations prior to use.
XACML Profile for Role Based Access Control (RBAC):
Committee Draft 01
2. Referenced Documents
XACML Profile for Web Services (WS-XACML)
2.1 ASTM Standards:
2.7 NIST Standards:
E1762 Guide for Electronic Authentication of Health Care
NIST Special Publication 800-33 Underlying Technical
Information
Models for Information Technology Security,
E1985 Guide for User Authentication and Authorization
(Stoneburner), December 2001
E1986 Guide for Information Access Privileges to Health
NIST Special Publication 800-95 (Draft) Guide to Secure
Information
Web Services, (Singhal, et al), September 2006
E2084 Specification for Authentication of Healthcare Infor-
NIST Special Publication 800-100 Information Security
mation Using Digital Signatures (Withdrawn 2009)
Handbook:AGuideforManagers,(Bowen,etal),October
E2212 Practice for Healthcare Certificate Policy
2.2 ANSI Standards:
FIPS PUB 66 Standard Industrial Classification (SIC)
X9.45 Enhanced Management Controls Using Digital Sig-
Codes
natures and Attribute Certificates
INCITS 359 Role-Based Access Control
3. Terminology
3.1 Definitions:
3.1.1 access control decision function (ADF),
This guide is under the jurisdiction of ASTM Committee E31 on Healthcare
n—specialized function that makes access control decisions by
Informatics and is the direct responsibility of Subcommittee E31.25 on Healthcare
applying access control policy rules to a requested action; see
Data Management, Security, Confidentiality, and Privacy.
policy decision point.
Current edition approved March 1, 2013. Published March 2013. Originally
approved in 2007. Last previous edition approved in 2007 as E2595–07. DOI:
10.1520/E2595-07R13.
For referenced ASTM standards, visit the ASTM website, www.astm.org, or
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM AvailablefromHealthLevelSeven,Inc.,3300WashtenawAve.,Suite227,Ann
Standards volume information, refer to the standard’s Document Summary page on Arbor, MI 48104.
the ASTM website. Available from Internet Engineering Task Force, www.ieft.org/rfc.html.
3 7
The last approved version of this historical standard is referenced on Available from International Organization for Standardization (ISO), 1 rue de
www.astm.org. Varembé, Case postale 56, CH-1211, Geneva 20, Switzerland, http://www.iso.ch.
4 8
Available fromAmerican National Standards Institute (ANSI), 25 W. 43rd St., Available from www.oasis-open.org/specs/index.php.
4th Floor, New York, NY 10036, http://www.ansi.org. Withdrawn Feb. 8, 2005.
E2595 − 07 (2013)
3.1.2 access control enforcement function (AEF), applying to all the different types of revocation lists, including
n—specialized function that is part of the access path between CRLs, ARLs, ACRLs, and so forth.
a requestor and a protected resource that enforces the decisions
3.1.15 certificate validation, n—process of ensuring that a
made by the ADF; see policy enforcement point.
certificate is valid, including possibly the construction and
3.1.3 access control information (ACI), n—any information
processing of a certification path, and ensuring that all certifi-
used for access control purposes, including contextual infor-
cates in that path have not expired or been revoked.
mation.
3.1.16 claimant, n—entityrequestingthatasensitiveservice
3.1.4 attribute certificate (AC), n—data structure that in-
be performed or provided by a verifier based on the claimant’s
cludes some attribute values and identification information
privileges as identified in its proffered attribute assertion,
about the owner of the attribute certificate, all digitally signed
attribute certificate, or subject directory attributes extension of
by an attribute authority (this includes certificates that an
their public-key certificate.
authority issues to itself) and this authority’s signature serves
3.1.17 credential, n—information describing the security
as the guarantee of the binding between the attributes and their
attributes (identity or privileges or both) of a user or other
owner.
principal.
3.1.4.1 Discussion—Types: role specification and role as-
10 3.1.17.1 Discussion—Credentials are claimed through au-
signment described in Ref (1).
thentication or delegation and used by access control.
3.1.5 attribute authority (AA), n—authority, trusted by the
3.1.18 delegation, n—conveyance of privilege from one
verifier to delegate privilege, that issues attribute certificates.
entity that holds such privilege to another entity.
3.1.6 attribute authority revocation list (AARL),
3.1.19 delegation path, n—ordered sequence of credentials
n—revocation list containing attribute certificates issued to
that can be processed to verify the authenticity of a claimant’s
attribute authorities that are no longer considered valid by the
privilege.
certificate issuer.
3.1.20 domain, n—set of objects that a subject is allowed to
3.1.7 attribute certificate revocation list (ACRL),
access.
n—revocation list containing attribute certificates issued to
claimants that are no longer considered valid by the certificate
3.1.21 environmental variables, n—those aspects of policy
issuer.
required for an authorization decision that are not contained
3.1.8 authority, n—entity responsible for the issuance of within structural structures but are available through some
certificates. local means to a verifier (for example, time of day or current
3.1.8.1 Discussion—Two types are defined in this guide: account balance).
certificate authority that issues public-key certificates and
3.1.22 functional role, n—job function within the context of
attribute authority that issues attribute certificates.
an organization whose permissions are defined by operations
3.1.9 authorization, n—granting of rights that includes the
on tasks, scenarios, aggregations, or data objects.
granting of access based on access rights.
3.1.22.1 Discussion—Functional roles provide detailed per-
missions defining what a user can do within the context of an
3.1.10 authorization credential, n—signed assertion of a
user’s permission attributes. application. Examples include permissions to create an order,
permission to sign a check, permission to read a database row,
3.1.11 authority revocation list (ARL), n—revocation list
and so forth. A functional role applies to a workflow’s
containing public-key certificates issued to authorities that are
individual process tasks.
no longer considered valid by the certificate issuer.
3.1.23 interoperable role, n—as defined by HL7, a job
3.1.12 authority certificate, n—certificate issued to an au-
function within the context of two or more organizations
thority (for example, either to a certification authority or to an
representing the lowest common level of interoperable permis-
attribute authority).
sions defined by a standardized vocabulary.
3.1.13 business partner agreement, n—document used to
3.1.24 owner, n—entity to whom some privilege has been
demarcate the legal, ethical, and practical responsibilities
delegated either directly from the source of authority or
between subscribers to a privilege management infrastructure
indirectly through another attribute authority.
(PMI) and between cooperating PMI implementations.
3.1.24.1 Discussion—An owner asserts its claim to that
3.1.14 certificate revocation list (CRL), n—signed list indi-
privilege by presenting authoritative credentials to a verifier
catingasetofcertificatesthatarenolongerconsideredvalidby
and acting as a claimant for its privilege.
the certificate issuer.
3.1.14
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.