uc enterprise architecture principles - ucla · uc enterprise architecture principles a. technology...

UC Enterprise Architecture Principles

A. Technology Principles

1. Principle: Interoperability Statement Solution, software and hardware implementations should conform to defined standards that promote interoperability objectives for data, applications, and technology. Rationale Standards-based interoperability supports data sharing, consistent access, reuse and the efficient consumption of services regardless of service location, platform or implementation specifics. Interoperability allows us to leverage existing IT assets and more easily integrate new ones while simultaneously providing flexibility for product selection and development at the campus level. Implications

UC defined/selected interoperability standards will be followed unless there is a compelling business reason to implement a non-standard solution.

Interoperability planning may lead to requirements for more sophisticated messaging software, common practices and infrastructure, in order to enable its full benefit.

Development and design for interoperability may involve additional upfront effort as compared to developing "one-off" or stand-alone solutions. Long term dividends in effectiveness, efficiency and durability offset the additional upfront effort/expense.


A. Data Architecture Principles

1. Principle: Data Naming and Definitions Statement: Data is formally named and defined across the enterprise, meaning that data names and definitions have a recognized form, structure, consistent with accepted enterprise data naming and definition standards. Rationale: Data is readily identifiable when the meaning of data is conveyed by the data name. Data definitions establish data that is easily, uniquely and commonly understood. Readily identifiable, uniquely and commonly understood data facilitates data sharing, attenuates the drive to create localized silos of redundant data and improves the efficiency and effectiveness of enterprise decision making. Implications: Practices of data governance are required to ensure that

standards of formal data naming, data naming abbreviations and data definitions are developed and adopted across the enterprise

data architects, business analysts and developers work with business and subject area experts to establish agreed upon data names, abbreviations and definitions that capture the business meaning of data

data stewards have the authority to manage data naming and definition accuracy

an enterprise metadata repository is available so that the identification and understanding of enterprise data is facilitated

an enterprise data management steering committee is available to resolve competing data names and definitions

data names and definitions where applicable utilize international and industry standards so as to enhance the reusability and interoperability of data


A. Application Architecture

1. Principle: Deliver Common Applications Statement: Common applications, defined as multiple instances of the same application across an enterprise or a single instance of an application shared by multiple organizational units, leverage many benefits that one-off applications, which serve only local organizational units, are unable to provide. Rationale: Common applications are efficient, providing economies of scale in application design, procurement, development, implementation, integration, management, and maintenance. Application support and expertise are concentrated on fewer distinct applications and can be leveraged across the University of California (UC) system. Application security is focused on fewer distinct applications, reducing the number of diverse threat 'surfaces' and thereby lowing risks and security costs. Common applications improve the consistency of business processes across the enterprise, which leads to lower operational costs and improved customer satisfaction. Finally, common applications facilitate a broad understanding of the associated application data that promotes information sharing for decision-making. Implications:

The formalization and evolution of UC common application development will be guided by this EA Principle

Each Location's application portfolio/repository will be used to evaluate existing applications against this Principle and will serve as the basis of assessment and development of future common applications.

Service management processes and dedicated staff will be available to manage the life cycle of all common applications.



1. Principle: Data is an Asset Statement: Data is an asset of measureable operational, tactical and strategic value to the enterprise and is managed with the same professional diligence as other enterprise assets. Rationale: Poor practices of data management are realized in redundant data stored in silos across the enterprise. These silos are often only known to and accessed by a relative few. The demand of other business units for the same data results in a spiral of redundancy that is costly to the enterprise and undermines effective decision making. The objective of professional data management is to ensure that the data is not only accurate, timely and relevant but is also known to exist, readily identifiable, commonly understood, easily accessed, sharable across the enterprise and secure. As such, professionally managed data is the basis of effective decision making. To optimize its value as an asset enterprise data is managed in accordance with established data management standards and accepted best practices. Implications: Practices of data governance are required to ensure that

a metadata repository exists to determine if and where data exists

data is formally named (readily identifiable) and defined (commonly understood)

data stewardship (responsibility, accountability) replaces data ownership (control)

data stewards are granted the authority and means to manage data accuracy, currency and quality

appropriate users have timely access to required data

data is sharable across the enterprise, recognizing that access to data enhances the efficiency and effectiveness of decision making

data is protected from unauthorized use and disclosure

a data governance council with enterprise representation is established to decide on data governance policy, processes and enforcement

Scope: This principle encompasses all data required by and available to the enterprise so as to enable the enterprise to successfully fulfill its mission. This includes and is specific to all structured and unstructured operational and decision support data. Operational data is defined as data collected through the provision of all services or products of the enterprise. Decision support data is defined as the data used for operational, tactical and strategic decision making across the organization. All other data such as academic research data is outside the scope of this principle.



1. Principle: Data is Shared Statement: Data is an asset to be shared across the enterprise. Rationale: Data shared from a single and authoritative source reduces the tendency to develop data silos across the enterprise, loweres development and maintenance costs and improves the consistency of data relied upon for enterprise decision making. Implications: Data sharing requires the implementation of enterprise architecture standards and procedures that

provide the specifications for formal data naming, comprehensive data definitions and the capture of business, technical, procedural and stewardship metadata

achieve the interoperability objectives for data, application and technology

guarantee that data sharing does not compromise confidential data

allow shared data to be relied upon by users to execute their respective tasks



1. Principle: Data Access Statement: Data is readily available for authorized use. Rationale: The ability of authorized users to readily access data improves operational performance and is fundamental to the support of a single authoritative system of record, thereby facilitating data sharing and reducing the drive to create localized data silos. Implications:

To be accessible requires that data is known to exist. An enterprise metadata repository facilitates the identification of data, i.e., if and where it exists

To be accessible to “appropriate” users requires security standards and procedures for authentication and authorization

Standards of data interoperability must be established to enable access and utilization of data across the enterprise

The manner in which information is accessed and displayed must be sufficiently flexible to accommodate a wide range of enterprise requirements



1. Principle: Data Stewardship Statement: Data within the enterprise is managed by data stewards. Rationale: Data is of optimal value to the enterprise when it is readily identifiable, easily understood, and trusted as accurate, timely and relevant. It is well established that attainment of these data quality attributes facilitates data sharing, engenders trust in data, and enhances the efficiency and effectiveness of decision support. Implications:

data stewardship (responsibility, accountability, authority) replaces data ownership (control)

data stewards are experts within the business areas most pertinent to the data that is under their purview

data stewards are granted the authority and the means to manage data accuracy, currency and quality

data stewards work with metadata managers and business experts to develop and administer data names and definitions within a UC enterprise metadata repository


A. Security Architecture

1. Principle: Data is Secure Statement: Data is an enterprise asset of measurable operational, tactical and strategic value. Data is to be secure from unauthorized access and utilization The confidentiality, integrity and availability of data is protected. Rationale: There are strong business, legal, and ethical reasons to protect data. Business reasons include the need for enterprise data to be trusted as accurate and of high integrity, and free from unauthorized access or modification. Legal requirements include, but are not limited to, the Payment Card Industry Data Security Standard (PCI DSS), the California Information Practices Act, the Health Insurance Portability and Accountability Act (HIPAA), the Family Educational Rights and Privacy Act (FERPA) among many others. Ethically the University is concerned with protecting itself, its employees, students and others from harm as a result of failure in the data’s confidentiality, integrity, or availability. Implications:

· Confidentiality, integrity and availability are independent factors. For instance, certain data may be accessible to the public (i.e. non-confidential), but must not be altered except by authorized individuals (integrity).

· Authentication only establishes that someone is who (s)he says (s)he is; but does not establish that the

person is authorized to create, access, modify or destroy any of that data. · Authorization may be tied to a person's identity alone, or it may also be conditioned upon that person's

role or attribute(s)· Data encryption approaches can be used to help ensure confidentiality, and even ensure integrity.

Encryption may be applied to data at rest (data storage) or to data in motion (data transmission). The adequacy of the encryption applied should be in proportion to the level of risk and the value of the data being protected.

· Security requirements are be end-to-end: that is, data protection goes beyond the University to include

suppliers, contractors, business partners, and other parties. · Adherence to certain security or privacy standards may be contractually imposed on the University, such

as FISMA/NIST. These requirements may apply to a specific business unit or to the entire University. · Failure to secure protected information can even result in civil or criminal liability, reputational damage to

the University, and usually will require remediation measures, such as breach notifications, data review and cleansing, re-issuance of user credentials, and re-accreditation and certification of information systems.

· Privacy is closely related to data security, but has distinct properties. The University has committed itself

to ensuring privacy in accordance with applicable laws, regulations and best practices. The concept of "privacy by design" are employed, fair information practices are adhered to, and guidelines such as The OECD Privacy Framework should be considered when designing applications or systems. Note: Definitions for terminology used in this document may be found in the ITS EA and Security Glossary on the UCOP EABOK SharePoint site.

https://sp2010.ucop.edu/sites/its/apptech/enterprisearchitecture/EABoK/TheEAGlossary/Enterprise%20Architecture%20Glossary.htm#PCI_DSS

https://sp2010.ucop.edu/sites/its/apptech/enterprisearchitecture/EABoK/TheEAGlossary/Enterprise%20Architecture%20Glossary.htm#Confidentiality

https://sp2010.ucop.edu/sites/its/apptech/enterprisearchitecture/EABoK/TheEAGlossary/Enterprise%20Architecture%20Glossary.htm#Integrity

https://sp2010.ucop.edu/sites/its/apptech/enterprisearchitecture/EABoK/TheEAGlossary/Enterprise%20Architecture%20Glossary.htm#Availability

https://sp2010.ucop.edu/sites/its/apptech/enterprisearchitecture/EABoK/TheEAGlossary/Enterprise%20Architecture%20Glossary.htm#Authentication

https://sp2010.ucop.edu/sites/its/apptech/enterprisearchitecture/EABoK/TheEAGlossary/Enterprise%20Architecture%20Glossary.htm#Authorization

http://www.ucop.edu/procurement-services/_files/appendix_ds.doc%26sa=U%26ei=2E9ZU7KoL8GbyASP5IGgBQ%26ved=0CAUQFjAA%26client=internal-uds-cse%26usg=AFQjCNFMtPvtIT-g4tl33DfPbeLvgGzh-g

http://www.privacybydesign.ca/content/uploads/2014/01/PbDBook-From-Rhetoric-to-Reality-ch8.pdf

http://www.oecd.org/sti/ieconomy/2013-oecd-privacy-guidelines.pdf

http://www.oecd.org/sti/ieconomy/2013-oecd-privacy-guidelines.pdf

https://sp2010.ucop.edu/sites/its/apptech/enterprisearchitecture/Lists/Definitions/AllItems.aspx?InitialTabId=Ribbon.ListItem&VisibilityContext=WSSTabPersistence

https://sp2010.ucop.edu/sites/its/apptech/enterprisearchitecture/Lists/Definitions/AllItems.aspx?InitialTabId=Ribbon.ListItem&VisibilityContext=WSSTabPersistence


A. Technology Architecture

Statement Information technology investments prioritize common, shared and reusable enterprise business capabilities. Rationale Investments in information technology that prioritize the provisioning of common capabilities:

efficiently meet enterprise requirements of multiple clients and business units

improve the time-to-value in service utilization

lower the resources and costs required to maintain and upgrade

reduce the long-term downstream costs of redundant and dissimilar technology Implications Enterprise information technology investment decisions reflect the priorities of a UC Enterprise Information Technology Strategic Plan based on shared business capabilities, reuse potential and time-to-value. Enterprise information technology investment decisions are formally reviewed with priority given to enterprise business capabilities while acknowledging valid instances of requirements for singular, localized functionality. Information regarding the location, purpose, capabilities and other identifying attributes of information technology, including applications and services, is captured, managed and made accessible through an enterprise information technology metadata repository.


A. Technology Architecture

1. Principle: Deliberately Plan Technology Platform Investments Statement University of California's selection of technology platforms improves our technology sustainability; and maximizes overall UC IT service delivery capacity and economy. Rationale

Investing in common technology platforms that are standards-based, interoperable, and sustainable lowers overall costs and improves UC’s capacity to deliver services efficiently. Standardizing on common platform technology across UCs grants greater flexibility and efficiency while enhancing maintainability of the overall technology base ; thereby also containing provisioning and ongoing maintenance costs. Since vendor-specific skills tend to be expensive, focusing support and resources on preferred technology 'stacks', deepens UC-wide knowledge and skills along particularly useful areas. Implications Introduction of new technologies are evaluated against this principle, with available selections constrained by those that conform to adopted technology standards and guidelines. Best practice libraries for extending common technologies will be developed and made universally accessible to aid in speeding customizations, and reducing time/cost of delivery by leveraging economy of scale. IT organizations publish and update their current portfolios, comprising the UC repository of technology choices, from which they will base individual platform selection decisions.

EABok EAAssets: Federated authentication protocols(Cross-campus Applications) I Like It Tags &

Notes

EAAID EAA-006

EAAType Standard

EAATitle Federated authentication protocols (Cross-campus Applications)

EAADescription Web-based applications authenticating users from multiple campuses will use SAML 2.0 to authenticate and present information interactively to applications.

SAML Assertions must always be signed.•SAML Assertions should be encrypted.•

SAML Resource Providers should be able to interact with multiple Identity Providers (i.e., provide discovery services to allow users to select their home campus)

EAASubmittedBy UCOP - Eric Goodman

EAAStatus Current

EAAScope System Wide

EAALink User Identification Attributes

EAADiscussion

EAAIDCOPY EAA-006

Attachments SAML2.docx

Created at 7/11/2013 10:49 AM by Jerome McEvoyLast modified at 8/15/2014 10:46 AM by Jerome McEvoy

Close

Page 1 of 1EAAssets - Federated authentication protocols (Cross-campus...

10/28/2014https://sp2010.ucop.edu/sites/its/apptech/enterprisearchitecture/EABoK/Li...

EABok EAAssets: User Identification AttributesI Like It Tags &

Notes

EAAID EAA-007

EAAType Standard

EAATitle User Identification Attributes

EAADescription Applications will identify users by leveraging UCTrust attributes intended for this purpose. This includes both attributes that identify users individually (e.g., “unique IDs”) and those that identify users by categories (e.g., “Faculty/Staff”)

EAASubmittedBy UCOP - Eric Goodman

EAAStatus Current


EAALink Federated authentication protocols (Cross-campus Applications)

EAADiscussion

EAAIDCOPY EAA-007

Attachments Attributes.docxIdentificationUser


Close

Page 1 of 1EAAssets - User Identification Attributes


EABok EAAssets: Transactional (Restricted) Web ServiceStandards I Like It Tags &

Notes

EAAID EAA-008

EAAType Standard

EAATitle Transactional (Restricted) Web Service Standards

EAADescription Web Services utilized for UC business transactions involving PII or financial transactions require robust security and reliability.

Web Services classified as Restricted by UC Security Officers or Data Stewards are subject to this standard also.

The standards utilized follow:

Communications Protocol: SOAP 1.1

Transport Protocol: HTTPS

Interface Definition: WSDL 1.1, RPC Literal

Data Exchange Formats: XML 1.0

Transport Security (mandatory):

Transport Level: 2Way SSL

Payload/content Security (mandatory):

Message Level: WSSecurity 1.1 (entire message)

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

EAASubmittedBy UCOP - Stephen Dean

EAAStatus Current


EAALink "Last Mile" security for Web Services

EAADiscussion

EAAIDCOPY EAA-008

Attachments soap.pdfvsrest


Close

Page 1 of 1EAAssets - Transactional (Restricted) Web Service Standards...


EABok EAAssets: Two-way SSL (Mutual Authentication)I Like It Tags &

Notes

EAAID EAA-009

EAAType Standard

EAATitle Two-way SSL (Mutual Authentication)

EAADescription

Twoway SSL is the standard for transport security for Business/Transaction Web Services.

2048 bit X.509 Certificates are to be used.

In twoway SSL, the identities of the client and server are represented by digital certificates. The SSL client application verifies the identity of the SSL server application, and then the SSL server application verifies the identity of the SSLclient application. This is also referred to as client authentication

Both the client and service obtain trusted certificates. The client and server do not have to exchange any kind of shared secret or perform other outofband communication. The trust between the two parties is established by having the certificates signed by amutually trusted certificate authority


EAAStatus Current

EAAScope De facto

EAALink Transactional (Restricted) Web Service Standards ; Provisioning or Generating X.509 Certificates; "Last Mile" security for Web Services

EAADiscussion

EAAIDCOPY EAA-009

Attachments Cryptography.docxIntroduction toAn


Close

Page 1 of 1EAAssets - Two-way SSL (Mutual Authentication)


EABok EAAssets: WS-Security 1.1 I Like It Tags &

Notes

EAAID EAA-011

EAAType Standard

EAATitle WS-Security 1.1

EAADescription

WSSecurity 1.1 is the standard for message level security for Business/Transactional Web Services

WSSecurity 1.1 is a security mechanism for Simple Object Access Protocol (SOAP) messages through encryption and integrity checkson all or part of the message.

http://www.w3.org/standards/xml/security


EAAStatus Current

EAAScope De facto

EAALink Transactional (Restricted) Web Service Standards ; "Last Mile" security for Web Services

EAADiscussion

EAAIDCOPY EAA-011

Attachments Security.docx-WSIntroduction toAn

Created at 7/11/2013 12:17 PM by Jerome McEvoyLast modified at 8/11/2014 8:23 AM by Jerome McEvoy

Close

Page 1 of 1EAAssets - WS-Security 1.1


EABok EAAssets: SSH File Transfer Protocol KeyI Like It Tags &

Notes

EAAID EAA-013

EAAType Standard

EAATitle SSH File Transfer Protocol Key

EAADescriptionThis is the standard SSH Key to be used for Secure FTP. Keys are to be installed on the target directory. Best practices are to avoid using the same key for Nonproduction and Production purposes.

SSH2 - the protocol version being used

RSA 2048 - which means the number of bits used in the encryption

No keyphrase needed for the the initial key generation

Sample UNIX command, (illustrative only) :

ssh-keygen -t rsa -b 2048

EAASubmittedBy UCOP - Stan Lee

EAAStatus Current

EAAScope De facto

EAALink Secure FTP set-up guidelines for UCPath

EAADiscussion

EAAIDCOPY EAA-013

Attachments Instructions.docxKeySSH

Created at 7/18/2013 12:04 PM by Jerome McEvoyLast modified at 8/11/2014 8:23 AM by Jerome McEvoy

Close

Page 1 of 1EAAssets - SSH File Transfer Protocol Key


EABok EAAssets: "Last Mile" security for Web ServicesI Like It Tags &

Notes

EAAID EAA-018

EAAType Standard

EAATitle "Last Mile" security for Web Services

EAADescription

After Transport level Security (e.g. SSL) has been terminated, the payload/content of the Web Service, if it contains Restricted Data elements, must be secured until consumed by the consuming application.

While the payload/content is traversing local data center infrastructure it may be subject to subject to eavesdropping/sniffing from individuals within the organization/network (thus the need for last mile security).

EAASubmittedBy UCLA - Shan Kandaswamy

EAAStatus Current


EAALink Transactional (Restricted) Web Service Standards ; Two-way SSL (Mutual Authentication) ; WS-Security 1.1

EAADiscussion

EAAIDCOPY EAA-018


Close

Page 1 of 1EAAssets - "Last Mile" security for Web Services


EA Artifact Item EA-033 Standard: Password Complexity and Online Guessing Resistance

Last Updated: 9/22/2014 Page 1 of 2 Editor: Eric Goodman

Standard: Password Complexity and Online Guessing Resistance

Description This UC standard defines two levels of password complexity (i.e., entropy) and online guessing resistance that application or data owners can request or mandate. This standard will allow data stewards and system operators to agree to and enforce operational requirements against standard operational requirements, without the need to negotiate requirements on a system-by-system basis.

Single Sign On or shared authentication environments, where multiple systems authenticate using the same set of credentials, benefit by this standard as it allows for different application security requirements to be supported from a single account system. The standard will also help system stewards communicate the level of protection each system must provide before it may host data.

Requirements

Primary Requirement Any campus system authenticating users must be able to enforce password complexity and guessing resistance requirements appropriate to the highest security level required by any of the application(s) protected by that authentication system. Systems that support authentication to multiple applications (e.g., Active Directory DS, Kerberos, LDAP, Shibboleth IdPs) and where only some accounts meet the maximum requirements must be able to identify which accounts meet each requirement level so that they can ensure that only appropriate accounts are used to access each integrated application.

In SAML-based federation, and specifically within UCTrust, authentication assertions must be able to identify an account’s compliance with one of the levels of this standard as part of the authentication assertion. The exact mechanism for providing this qualifier is to be defined by the UCTrust group.

The levels of protection defined are adapted from the InCommon IAP requirements for Bronze and Silver Levels of Assurance:

Requirement Area Level 1 Requirement Level 2 Requirement Minimum Password Entropy 25 bits 30 bits Maximum Chance of Online Guessing 1:2^10 (1 in 1024) 1:2^14 (1 in 65536)

Minimum Password Entropy is a minimum limit on a passwords complexity as measured in NIST 800-63, Appendix A, Table A-1.

Maximum Chance of Online Guessing is a limit on the number of random guesses that can be made over the lifetime of a password. The system cannot allow for a number of online guesses for a given password that would allow a higher chance of guessing than this value.

Alternate Requirement Some applications are limited to using PINs (numbers only, typically 4-6 digit number) in place of actual passwords. 6 digit PINs, even if randomly generated, only provide 20 bits of entropy (4 digit, randomly generated PINs provide 13 bits of entropy). In the case of PIN-based systems, an alternate standard can be employed, based on strict restrictions on the allowable rate of PIN guessing. These alternate requirements are taken from NIST 800-63-2 and FICAM TFPAP 2.0:

EA Artifact Item EA-033 Standard: Password Complexity and Online Guessing Resistance


Requirement Area Level 1 Requirement Level 2 Requirement Minimum PIN length –Random Assignment 4 digits (13 bits of entropy) 6 digits (20 bits of entropy) Maximum Guessing Rate 100 failed attempts/30 days 100 failed attempts/30 days

Standards References The requirements of this standard are defined referencing the following sources.

InCommon Identity Assurance Profile (IAP) 1.2 o Section 4.2.3.2, Basic Resistance to Guessing Authentication Secret o Section 4.2.3.3, Strong Resistance to Guessing Authentication Secret

NIST (National Institute of Standards and Technology) 800-63-2 o Section 6.3.1.1; Table 6; Memorized Secret Token requirements o Appendix A, Estimating [Password] Entropy and Strength

FICAM (Federal Identity, Credential and Access Management) TFPAP (Trust Framework Provider Adoption Process) 2.0

o Appendix A-2, Tokens, Assurance Level 2 Tokens Trust Criteria; Criteria #4 for Memorized Secret Tokens

OMB (Office of Management and Budget) M-04-04 o While this UC standard draws from the formal Level of Assurance (LoA)definitions in the OMB

standard, the UC standard is intentionally narrower in scope than an overall LoA program.

Policy References The need for Campus-level standards around password and authentication credential complexity is supported by the following UC-wide policies:

BFB-IS-3 Electronic Information Security o Section III.C.2. Operational and Technical Controls

BFB-IS-11 Identity and Access Management o Section III.E. Level of Assurance

Both of these BFB IS series policies identify for passwords to be difficult to guess and that there should be a high level of confidence that the credential is only usable by the person to whom it was issued.

EA Artifact Item EA-034 Standard: Credential Renewal/Password Reset


Standard: Credential Renewal/Password Reset

Description This UC standard defines approved methods for allowing users to reset their passwords via self-service methods, either for normal password change processes, or in an “I forgot my password” service mode.

Requirements A user must be authenticated for purpose of credential renewal or password reset by any of the following methods:

1. By use of a non-expired and valid credential. I.e., by successfully logging in with the current password. 2. By use of a single-use secret delivered to the account holder by means of a pre-registered out-of-band

delivery mechanism. Typically this will be via an email to a pre-registered email address, or a text message to a pre-registered SMS number.

3. By the user supplying the correct answers to pre-registered personalized questions designed to be difficult for any other person to know.

If none of these methods is successful then the user must re-establish her or his identity as would be required if the user were establishing a new account.

When a password is reset by a user, a “best effort” should be made to ensure that recent passwords are not re-used, however this standard currently applies no formal requirements for achieving such a best effort.

Standards References The following sources inform the definition of this standard:

InCommon Identity Assurance Profile (IAP) 1.2 o Section 4.2.4.3, Credential Renewal or Re-Issuance

NIST (National Institute of Standards and Technology) 800-63-2 o Section 6.3.1.1 (Table 6)

FICAM (Federal Identity, Credential and Access Management) TFPAP (Trust Framework Provider Adoption Process) 2.0

o Appendix A-2, Assurance Level 2 Security Trust Criteria

Policy References None

EA Artifact Item EA-035 Standard: Password Storage


Standard: Password Storage

Description This UC standard defines requirements for protecting stored user passwords and their hashes. It defines two levels of security.

Level 1: Applies to any system, requiring that passwords not be stored in plaintext form Level 2: Applies to more sensitive systems, defining more stringent requirement that limits the acceptable

forms of encryption and hashes for protecting stored passwords

Single Sign On or shared authentication environments, where multiple systems authenticate using the same set of credentials, benefit by this standard as it allows for different application security requirements to be supported from a single account system. The standard will also help system stewards communicate the level of protection each system must provide before it may host data.

Requirements Any campus system that stores user passwords or hashes of the user’s password must protect those passwords from disclosure. Beyond UC Policy requirements for password protection, this standard sets forth two levels of security for protecting stored passwords, based on the sensitivity level of the data or access protected by that password.

When using SAML-based federated authentication, authentication assertions must indicate an account’s compliance with either of the levels of this standard by [there are multiple approaches; this should be discussed among UCTrust].

The levels of protection defined are adapted from the InCommon IAP requirements for Bronze and Silver assurance levels:

Level 1 Requirement Level 2 Requirement 1. Authentication Secrets shall not be

stored as plaintext. Access to stored Secrets and to plaintext copies shall be protected by discretionary access controls that limit access to administrators and applications that require access.

2. Plaintext passwords or Secrets shall not be transmitted across a network.

Authentication Secrets shall not be stored as plaintext. Access to encrypted stored Secrets and to decrypted copies shall be protected by discretionary access controls that limit access to administrators and applications that require access. Three alternative methods may be used to protect the stored Secret: 1. Authentication Secrets may be concatenated to a variable salt (variable

across a group of Authentication Secrets that are stored together) and then hashed with an Approved Algorithm (per FIPS 140-2) [strong?] so that the computations used to conduct a dictionary or exhaustion attack on a stolen Authentication Secret file are not useful to attack other similar Authentication Secret files. The hashed Authentication Secrets are then stored in the Authentication Secret file. The variable salt may be composed using a global salt (common to a group of Authentication Secrets) and the userID (unique per Authentication Secret) or some other technique to ensure uniqueness of the salt within the group of Authentication Secrets; or

2. Store Secrets in encrypted form using Approved Algorithms (per FIPS 140-2) [strong?] and decrypt the needed Secret only when immediately required for authentication; or

EA Artifact Item EA-035 Standard: Password Storage


3. Any method protecting stored Secrets at NIST [SP 800-63] Level 3 or 4 may be used.

Standards References The requirements of this standard are defined referencing the following sources.

InCommon Identity Assurance Profile (IAP) 1.2 o Sections 4.2.3.4 Stored Authentication Secrets and 4.2.3.5 Basic Protection of Authentication

Secrets NIST (National Institute of Standards and Technology) 800-63-2

o Section 7.3 Token and Credential Management Assurance Levels FIPS (Federal Information Processing Standards) 140-2

o Annex A Approved Security Functions OMB (Office of Management and Budget) M-04-04

o While this UC standard draws from the formal Level of Assurance (LoA)definitions in the OMB standard, the UC standard is intentionally narrower in scope than an overall LoA program.

Policy References The need for Campus-level standards around password and authentication credential complexity is supported by the following UC-wide policies:

BFB-IS-3 Electronic Information Security o Section III.C.2. Operational and Technical Controls

EABok EAAssets: PGP Encryption for files I Like It Tags &

Notes

EAAID EAA-039

EAAType Standard

EAATitle PGP Encryption for files

EAADescriptionThis standard is intended to be used to encrypt file content.

Applicable to files containing Restricted Infomation.

The encryption scheme is:

OpenPGP (IETF proposed standard RFC 4880) - 2048 bit

http://www.ietf.org/rfc/rfc4880.txt

Using GnuPG instructions: https://sp2010.ucop.edu/sites/its/apptech/enterprisearchitecture/EA%20Artifacts/Security%20Architecture/GnuPG%20Instructions.docx

Note: If you are going to FTP an encrypted file - we recommend you use binary mode.

EAA039 - PGP Encryption for files.pdf

EAASubmittedBy UCOP - Jerome McEvoy

EAAStatus ITAGReview-30Day

EAAScope

EAALink Data is Secure; Interoperability; Secure FTP set-up guidelines for UCPath; SSH File Transfer Protocol Key

EAADiscussion

EAAIDCOPY EAA-039

Created at 9/5/2014 3:06 PM by Jerome McEvoyLast modified at 10/9/2014 2:30 PM by Jerome McEvoy

Close

Page 1 of 1EAAssets - PGP Encryption for files


uc enterprise architecture principles - ucla · uc enterprise architecture principles a. technology...

Documents