UCSF 650-16 Addendum E - PCI · 2020. 5. 19. · • To comply with data security requirements defined by Payment Card Industry Data Security Standards 3.1/3.2 (PCI-DSS) Scope: The

UCSF Internal Use Only (Proprietary)

1

UCSF 650-16 Addendum E - PCI


2

Table of Contents DOCUMENT HISTORY .............................................................................................................. 5SECTION 1 High Level Security Policy .................................................................................... 6

1.1 Policy Addendum Sections .................................................................................................... 71.1.1 Security Policy Addendum Sections .............................................................................. 7

1.2 Policy Addendum Review ................................................................................................ 71.3 Security Exceptions ....................................................................................................... 7

SECTION 2 Security Organization .......................................................................................... 82.1 Security Infrastructure ........................................................................................................... 8

2.1.1 Management Security Structure ..................................................................................... 82.1.2 Allocation of Security Responsibilities .......................................................................... 82.1.3 Sanction Policy ............................................................................................................... 92.1.4 Security Awareness ........................................................................................................ 9

2.2 Outsourcing ........................................................................................................................... 92.2.1 Security Requirements in Outsourcing Contracts and Service Providers ...................... 9

SECTION 3 Information Asset Classifications and Control ................................................. 113.1 Accountability for Assets .................................................................................................... 11

3.1.1 Inventory of Assets ....................................................................................................... 113.1.2 Risk Assessment ........................................................................................................... 11

3.2 Asset Classification ............................................................................................................. 113.2.1 Classification Guidelines .............................................................................................. 113.2.2 Asset Labeling and Handling ....................................................................................... 113.2.3 Document Destruction .................................................................................................. 12

SECTION 4 Personnel Security .............................................................................................. 134.1 Verifications ........................................................................................................................ 13

4.1.1 Verification of Personal Data ....................................................................................... 134.1.2 Employee Eligibility Verification ................................................................................ 13

4.2 Background Checks ............................................................................................................. 134.2.1 Criminal Record Check ................................................................................................ 13

4.3 Agreements .......................................................................................................................... 134.3.1 Non-Disclosure ............................................................................................................. 134.3.2 Harassment Policy ........................................................................................................ 13

5.1 Secure Areas ........................................................................................................................ 145.1.1 Physical Security Perimeter .......................................................................................... 145.1.2 Physical Entry ............................................................................................................... 145.1.3 Securing Unattended Offices, Rooms, and Facilities ................................................... 145.1.4 Working in Secure Areas .............................................................................................. 145.1.5 Isolated Delivery and Loading Areas ........................................................................... 14

5.2 Equipment Security ............................................................................................................. 155.2.1 Equipment Protection ................................................................................................... 155.2.2 Cabling Security ........................................................................................................... 155.2.3 Security of Equipment Off-Premises ............................................................................ 15

5.3 General Controls .................................................................................................................. 155.3.1 Clear Desk and Clear Screen ........................................................................................ 155.3.2 Regulations and Codes ................................................................................................. 155.3.3 Maintenance Records ................................................................................................... 155.3.4 Disaster Evacuation ...................................................................................................... 15


3

SECTION 6 Computer and Network Management ............................................................... 166.1 Operational Procedures and Responsibilities ...................................................................... 16

6.1.1 Change Control Procedures .......................................................................................... 166.1.2 Incident Management Procedures ................................................................................ 16

6.2 Protection against Malicious Software ................................................................................ 166.3 Housekeeping ...................................................................................................................... 17

6.3.1 Information Back-up ..................................................................................................... 176.3.2 Problem Tracking and Maintenance Logs .................................................................... 17

6.4 Systems Management .......................................................................................................... 176.4.1 System Controls ............................................................................................................ 176.4.2 Encryption Controls ...................................................................................................... 17

6.5 Network Management ......................................................................................................... 186.5.1 Network Controls ......................................................................................................... 18

6.6 Computer Media Handling and Security ............................................................................. 196.6.1 Management of Storage Media ..................................................................................... 196.6.2 Disposal of Data and Storage Media ............................................................................ 196.6.3 Data Retention .............................................................................................................. 20

6.7 Exchanges of Information and Software ............................................................................. 206.7.1 Information and Software Exchange Agreements ........................................................ 206.7.2 Security of Data and Computer Media in Transit ......................................................... 206.7.3 Electronic Commerce Security ..................................................................................... 206.7.4 Other Forms of Information Exchange ......................................................................... 21

SECTION 7 System Access Control ........................................................................................ 227.1 Business Requirements for Access Control ......................................................................... 227.2 User Access Management ................................................................................................... 22

7.2.1 User Registration & Revocation ................................................................................... 227.2.2 Privilege Management .................................................................................................. 227.2.3 User Password Management ........................................................................................ 227.2.4 Review of User Access Rights ..................................................................................... 23

7.3 Process Account Management ............................................................................................. 237.4 Network Access Control ...................................................................................................... 237.5 Operating System Access Control ....................................................................................... 23

7.5.1 System Log-on Procedures ........................................................................................... 237.5.2 User Identification and Authentication ......................................................................... 237.5.3 Use of System Utilities ................................................................................................. 247.5.4 Session Time Out .......................................................................................................... 24

7.6 Monitoring System Access and Use .................................................................................... 247.6.1 Event Logging .............................................................................................................. 247.6.2 Monitoring System Use ................................................................................................ 247.6.3 Clock Synchronization ................................................................................................. 24

7.7 Mobile Computing / Remote Access ................................................................................... 257.7.1 Mobile Computing ........................................................................................................ 257.7.2 Remote Access ............................................................................................................. 25

SECTION 8 System Development and Maintenance ............................................................. 268.1 Security Requirements of Systems ...................................................................................... 268.2 Security in Application Systems .......................................................................................... 26

8.2.1 Input Data Validation ................................................................................................... 268.2.2 Control of Internal Processing ...................................................................................... 26


4

8.2.3 Output Data Validation ................................................................................................. 268.2.4 Code Review ................................................................................................................. 268.2.5 Secure Coding ............................................................................................................... 268.2.6 Application Security Vulnerability Assessments ......................................................... 27

8.3 Cryptographic Controls ....................................................................................................... 278.4 Security of System Files ...................................................................................................... 27

8.4.1 Control of Operational Software .................................................................................. 278.4.2 Access Control to Program Source Library .................................................................. 278.4.3 Protection of System Test Data .................................................................................... 27

8.5 Security in Development and Support Processes ................................................................ 288.5.1 Integration Management ............................................................................................... 288.5.2 Outsourced Software Development .............................................................................. 28

SECTION 9 Business Continuity Management ...................................................................... 299.1 Aspects of Business Continuity Management ..................................................................... 299.2 Business Continuity Plan (BCP) ......................................................................................... 299.3 Disaster Recovery Planning (DRP) ..................................................................................... 299.4 Life / Health Safety (LHS) .................................................................................................. 299.5 Risk Management (RM) ...................................................................................................... 299.6 Responsibilities .................................................................................................................... 30

SECTION 10 Compliance .......................................................................................................... 3110.1 Compliance ........................................................................................................................ 31

10.1.1 Identification of Applicable Legislation ..................................................................... 3110.1.2 Safeguarding of Organizational Records .................................................................... 3110.1.3 Data Protection and Privacy of Personal Information ................................................ 31

10.2 Reviews of Security Control Requirements and Compliance ........................................... 3110.3 System Audit Controls ....................................................................................................... 31

APPENDIX A. Glossary of Terms ............................................................................................. 32


5

DOCUMENT HISTORY Document Status: In Review Revision History: Date of this revision: 06-28-2016 Date of Next revision:

Version Number

Revision Date Summary of Changes Changes Marked

1.0


6

SECTION 1 High Level Security Policy Purpose: This document outlines the requirements for information, locations, facilities, and devices processing, storing, or transmitting credit card information. Objective:

• To comply with data security requirements defined by Payment Card Industry Data Security Standards 3.1/3.2 (PCI-DSS)

Scope: The policy addendum covers all UCSF PCI-in-scope information used by UCSF and its affiliates. The information can include data stored on any computer, transmitted across networks, printed out or written on paper, sent by fax, stored on tape, electronically scanned, media, or spoken in conversation or over the telephone, hereafter referred to as an “information asset.” The policy addendum applies to any PCI-in-scope location or facility that is owned, leased, operated, or managed by UCSF housing any people, equipment, or information assets that are covered by this policy, hereafter referred to as “facility.” The policy addendum covers all persons seeking access to or usage of any UCSF PCI-in-scope information asset and is required to be reviewed and acknowledged, including UCSF full- or part-time employees; UCSF affiliates; contract staff; consultants; third-party suppliers; any other external parties to whom access may be granted for any reason. For purposes of scope for this document and any policies referred to by this document, all individuals that meet the above criteria will be hereafter referred to as “employees.” This policy addendum covers any piece of equipment or technology that is owned, leased, or managed by UCSF which is used to access any PCI-in-scope information asset, hereafter referred to as a “managed device.” This addendum collectively refers to PCI-in-scope information, locations and facilities, persons seeking access to or usage of PCI-in-scope information, and managed devices as “PCI assets.” Owner: The ownership of changes will be governed by the UCSF PCI-DSS Compliance PCI Oversight Committee. This team will be referred to in the remainder of this document as “PCI Oversight Committee.” The IT Security team will review, enforce, and propose changes to PCI Oversight Committee. This team will consist of the Controller, Chief Information Officer, and Director of Information Security at a minimum.


7

1.1 Policy Addendum Sections

1.1.1 Security Policy Addendum Sections The Information Security Policy Addendum includes adoption and full implementation of Addendum Sections as part of its comprehensive approach.

• Security Organization • Asset Classification and Control • Personnel Security • Physical and Environmental Security • Computer and Network Management • System Access Control • System Development and Maintenance • Business Contingency Planning • Compliance

1.2 Policy Addendum Review A review of the Information Security Policy Addendum will be performed annually or whenever deemed necessary by the IT Security Team and by the PCI Oversight Committee. The policy addendum review will include making necessary changes in accordance with ongoing and evolving business, technical or environmental risks and their impact to the organization, and changes to the PCI-DSS. All changes are subject to Organization¹s change control process and shall be recorded using version control that will encompass version number, date, change coordinator and change approver.

1.3 Security Exceptions Exceptions to the Information Security Policies addendum are permitted in instances where it has been demonstrated that risk has been adequately mitigated as determined by the CISO/Director of Information Security or PCI Oversight Committee. Exceptions must be authorized and signed by PCI Oversight Committee member at written request.


8

SECTION 2 Security Organization Objective: The objective of this statement is to outline the management of security within UCSF by establishing an

appropriate infrastructure and defining and allocating security responsibilities for PCI Assets. Scope: This policy addendum statement covers the management framework used to initiate and control the implementation of information security of PCI assets within UCSF.

Owner: PCI Oversight Committee

2.1 Security Infrastructure

2.1.1 Management Security Structure The Director of Information Security will ensure the Enterprise Security Program is appropriately represented and supported within all levels of UCSF. Each UCSF facility will have a Unit Department Official or designee, typically the Data Security Compliance Program Champion that will be responsible to maintain any necessary documentation needed at the facility and help enforce all UCSFs information security policies with the help and coordination of the Director of Information Security.

2.1.2 Allocation of Security Responsibilities The IT Security Team is responsible for the ownership of the UCSF Security Program, the ownership of the Information Security Policy, and securing PCI Oversight Committee approval on the acceptance or mitigation of enterprise security risks. The Director of Information Security is responsible for:

• Setting strategy and direction for the Information Security Program; • Administration and maintenance of the Information Security Program; • Creating and distributing security policies, standard, and procedures; • Identification and escalation of enterprise security risks to the Corporate Management Team; • Delivery of enterprise security services that help identify enterprise risks and enable the Security

Program; • Identification of Enterprise and Site specific risk; • Monitoring and analyzing security alerts and distributing information to appropriate information

security and business unit management personnel; • Creating and distributing security incident response and escalation procedures; • Evaluating compliance with security policies and control requirements during the course of audits; • Assessing risk mitigation; • Recommending improvements to controls; • Administration and maintenance of the physical security components; • Reviewing existing physical security policies, procedures and processes and recommending

improvements.


9

The Unit Department Official or designee is responsible for:

• Coordinating the implementation of the Security Program within a facility; • Administration and maintenance of the facilities security program; • Coordinating the implementation of security policies, standards and procedures; • Identification and escalation of facility security risks.

System Administrators’ and Network Engineers’ responsibilities are to:

• Configure systems to meet the security controls documented in Security Policies and Standards; • Manage system security mechanisms and review audit trails for attempts to bypass or subvert

system security controls; • Inform the Director of Information Security of known or suspected compromises of sensitive

information assets and violations of Security Policies and Standards and assist in security incident response efforts.

• Manage and maintain authentication systems and user accounts. Even if the responsibilities are delegated to other teams from time to time, ultimate responsibility is with the System Administrators and Network Engineers.

• Monitoring and controlling all access to data. Employees’ responsibilities are to:

• Take all necessary precautions to protect the confidentiality, integrity, and availability of the Organization information assets of which they are provided use;

• Limit use of information assets to authorized business purposes only; • Read and sign a UCSF Confidentiality Agreement, including the UC Privacy Policy and

Acknowledgement of responsibility; • Comply with the provisions of all policies, standards, and applicable procedures listed in the

UCSF Confidentiality Agreement; • Inform the Director of Information Security of known or suspected compromises of sensitive

information assets or violations of Security Policies and Standards.

2.1.3 Sanction Policy Any employee found to have violated these policies may be subject to disciplinary action, up to and including termination of employment (See “Authorized and Acceptable Use of Electronic Information Resources” - Policy Number 650-18: at https://policies.ucsf.edu/policy/650-18; also” Workforce Sanctions for Patient Privacy Violations” - Policy Number 200-32 at http://policies.ucsf.edu/policy/200-32).

2.1.4 Security Awareness Security awareness training and policy review is required to be completed by all employees upon hire and at least annually, this includes periodic security reminders that are sent out.

2.2 Outsourcing

2.2.1 Security Requirements in Outsourcing Contracts and Service Providers The security requirements of any outsourcer or service provider that is engaged by UCSF is subject to this policy and must be addressed so in a contract. The contract must be agreed upon by the parties and reviewed by the Privacy, Legal, and Risk (PLR) Committee. Such contracts must include agreements to comply with the UCSF Information Security Policy and any other relevant policies, standards, and procedures. Prior to engaging an outsourcer or service provider, due diligence must be performed and documented. A list of outsourcers and service providers must be maintained if used. Within the list track the status of the outsourcers or service providers PCI DSS compliance status. Any outsourcer or service provider


10

having access to the CDE is required to comply with this addendum; this requirement must be stated explicitly in the contract.


11

SECTION 3 Information Asset Classifications and Control Objective: The objective of this statement is to insure that information assets receive an appropriate level of protection. Scope: This statement covers Information Asset Classification and Control and addresses the requirements for Information Assets to be identified, assessed and protected according to their level of sensitivity and criticality. Owner: IT Security Team

3.1 Accountability for Assets

3.1.1 Inventory of Assets All information assets must be clearly identified, documented and maintained with its ownership, custodianship, and security classification. An information asset inventory must be kept up to date, accounting for system, organizational or functional changes. Periodic asset inventories must be performed at least annually.

3.1.2 Risk Assessment The Unit Department Official or designee will help perform a risk assessment to assist with properly classifying any information asset located within the facility. The UCSF Systems team will perform an overall combined risk assessment across all facilities to properly classify all UCSF information assets. The Director of Information Security is responsible for providing guidance on how to perform a risk assessment and how the risk methodology should be used.

3.2 Asset Classification Each information asset will be classified to indicate the need, priorities and degree of sensitivity in order to ensure these assets receive an appropriate level of protection.

3.2.1 Classification Guidelines The information classification system defines an appropriate set of protection levels and communicates the need for special handling measures as follows: Public Public: Information accessible under the Public

Records Act is available to any person not withstanding their status or interest. Examples of public information include information made available to patient access via UCSF's public web sites.

Restricted Data

Restricted Data: Information, which is not public in nature, but can be disclosed to or used by UCSF representatives to carry out their duties providing there is no legal prohibition to disclosure. Examples of restricted information include individual workforce members’ personal e-mail.


12

Confidential Information

Confidential Information: Information that may or may not be protected by law but which is desired to be treated as confidential and protected accordingly. Access to confidential information is prohibited unless permitted by policy or exception to the law. In the case of legally confidential data, the exception may be contained within the law or regulation, or by court order or subpoena for the information. An example of confidential information is patients’ lab records viewed on the Summary Time Oriented Record (STOR) System by their physicians. PCI data also falls in this category.

Personal Information Personal Information: Any information that is

maintained by an agency that identifies or describes an individual, including, but not limited to, his or her name, social security number, physical description, home address, home telephone number, education, financial matters, and medical or employment history. It includes statements made by, or attributed to, the individual.

3.2.2 Asset Labeling and Handling All Data Security Compliance Program Control Points will define procedures for the labeling and handling of information assets based on the asset’s classification. These procedures must outline handling guidelines throughout the life cycle of the asset, including appropriate re-use or disposal.

3.2.3 Document Destruction Sensitive Information on paper shall be shredded and recycled by a firm specializing in the disposal of confidential records (i.e. Iron Mountain) or be shredded by an employee of our organization, authorized to handle such information (Refer to Records Management and Retention Policy Number 050-19 at “https://policies.ucsf.edu/policy/050-19”; UCOP BFB-RMP-2: Records Retention and Disposition Policy at “http://policy.ucop.edu/doc/7020454/BFB-RMP-2” and UCOP IS-3 Electronic Information Security at “http://policy.ucop.edu/doc/7000543/BFB-IS-3” ). Upon completion of the destruction/disposal, a record/log will be generated and retained as per internal data retention policy. This record will contain the following information: - Date of destruction; - Method of destruction; - Description of the disposed records; - Inclusive dates covered; - A statement that the records have been destroyed in the normal course of business; - The signatures of the individuals supervising and witnessing the destruction; Important: If the destruction is carried out by a third party:

• The data destruction shall be completed onsite in presence of a data custodian representative employee of the organization).

• In case of the destruction of PHI (protected healthcare Information), PII (personally identifiable information) and/or PCI (cardholder information) an official statement of destruction shall be provided and kept always available for the entitled entities verification.


13

SECTION 4 Personnel Security Objective: To establish the requirements which are for the protection of personnel within UCSF and safeguard the Organization. Scope: This statement applies to all UCSF employees and contractors.

Owner: PCI Oversight Committee

4.1 Verifications

4.1.1 Verification of Personal Data All employees are subject to the verification of the personal information they provide while applying or transferring to new positions. (Relevant education, Employment History, Reference Checks, etc.)

4.1.2 Employee Eligibility Verification As required by Federal Law all employees must provide proof of identity and complete an I-9 form.

4.2 Background Checks

4.2.1 Criminal Record Check In addition to the UCSF required background check those employees with bulk access to confidential data are required to have a criminal background check.

4.3 Agreements

4.3.1 Non-Disclosure All employees must sign an agreement to not disclose the Organization’s proprietary assets.

4.3.2 Harassment Policy All employees must read and sign the Organization’s Harassment Policy.


14

SECTION 5 Physical and Environmental Security Objective: The objective of this statement is to prevent unauthorized physical access, damage or interference to information services, which may result in loss or interruption of business activities. Scope: This statement covers the physical security and environmental protection of all UCSF facilities and information assets. Owner: Campus Facilities Services and Medical Center Facilities & Support Services

5.1 Secure Areas

5.1.1 Physical Security Perimeter All UCSF facilities must have appropriate controls that include provisions for fire, water, environmental and physical intrusion protection. In all UCSF facilities that contain shared space with non-UCSF entities, measures must be taken to ensure that UCSF information assets, managed devices and communication devices remain physically separated and properly secured from unauthorized physical access.

5.1.2 Physical Entry Secure areas must be protected by appropriate entry controls to ensure that only authorized personnel are allowed access, according to the “principle of least privileged.” These controls must include processes that address entry by visitors, escorts of visitors, audit trails, physical verification of a visitor, a review process for authorized and unauthorized access, and emergency procedures. An authorization process must be defined and describe procedures for granting, revoking, transferring and reviewing access to secure areas. The process must include an identified manager who is responsible for administering access. Each UCSF facility will utilize visitor badges that are clearly differentiated from normal user badges so employees can recognize visitors. Visitors in any UCSF facility must be escorted by a UCSF employee at all times. Each UCSF facility will contain a visitor log that will be maintained for a minimum of three months and must document the visitor’s name, the firm represented, and the employee authorizing physical access on the log. Video surveillance is to be used on all entry/exit points of each UCSF facility. Video is to be stored for at least three months, unless otherwise restricted by law.

5.1.3 Securing Unattended Offices, Rooms, and Facilities All information assets classified as restricted, confidential and personal information must be properly secured when unattended.

5.1.4 Working in Secure Areas All work areas of each UCSF facility are considered to be restricted access; only personnel authorized for access to each area may be present in the area unescorted.

5.1.5 Isolated Delivery and Loading Areas Delivery and loading areas must be controlled, and wherever possible, isolated from other work areas to avoid unauthorized access.


15

5.2 Equipment Security

5.2.1 Equipment Protection Adequate protection must be in place to minimize the risk of any UCSF managed device being left in a degraded or inoperable state from potential threats including theft, manipulation, fire, water, dust, or electrical supply interference. All UCSF managed servers and network equipment should be physically secured or kept in locked or controlled areas. The level of security required to access any UCSF managed device will be considered based on its functional criticality. Physical access to UCSF managed critical devices will be restricted to only authorized employees.

5.2.2 Cabling Security Power cables and telecommunications cabling carrying data or supporting information services must be protected from interception, interference, and damage.

5.2.3 Security of Equipment Off-Premises

Each facility that utilizes any UCSF managed device will ensure that the device is wiped of any confidential or proprietary information before that device is retired or removed from service as a UCSF managed device. Each Unit Department Official or designee will maintain a log of all equipment that leaves the UCSF facility as it is retired or removed from service.

5.3 General Controls

5.3.1 Clear Desk and Clear Screen All UCSF areas associated with protected data (PCI, HIPAA, PII, etc.) will enforce a clear desk and clear screen practice to reduce the risk of unauthorized access, loss, or damage to proprietary or confidential information.

5.3.2 Regulations and Codes The Site Director and/or Unit Department Official or designee will ensure that all physical security measures comply with relevant local regulations and codes. Examples include labor, fire, building and electrical regulations and codes.

5.3.3 Maintenance Records The Unit Department Official or designee will ensure that a document exists for any repairs and modifications to the physical components of a facility which are related to security (for example, hardware, walls, doors and locks).

5.3.4 Disaster Evacuation A documented evacuation plan specific to each UCSF facility will be followed for all facilities. The plan will include at minimum:

• Diagrams of evacuation routes, which are to be posted throughout the facility; • An alarm system which undergoes scheduled maintenance; • A plan testing schedule that is in place and practiced at least once annually; • A procedure for taking a “head count” once an evacuation has occurred.


16

SECTION 6 Computer and Network Management Objective: The objective of this statement is to ensure the correct and secure operation of UCSF managed network and computer systems. Scope: This statement covers the security of the UCSF managed network and computer systems.

Owner: ITSM/IT Security Team

6.1 Operational Procedures and Responsibilities

6.1.1 Change Control Procedures All UCSF managed devices used for production processing will follow a formal change control procedure, which is used to ensure that only authorized changes are made. This change control procedure must include the following for all production changes to software, hardware, communication networks, and related procedures:

• Documentation of change potential impact • Management sign-off • Testing of functionality • Back-out procedures

6.1.2 Incident Management Procedures The Director of Information Security is responsible for developing, maintaining, and organizing an in-house computer incident response process. At least annually, the Director of Information Security must train appropriate personnel and utilize simulated incidents to activate and test the adequacy of the incident response procedures. Formal reporting procedures are established, together with an incident response procedure, setting out the actions to be taken on receipt of an incident report. All employees and contractors must be made aware of the procedure for reporting security incidents, and must be required to report such incidents as quickly as possible. Suitable feedback processes must be implemented to ensure that those reporting incidents are notified of UCSF after the incident has been dealt with and closed. All affected parties by an incident such as business associates, governmental agencies, and/or others will be notified as per industry, federal, and state or compliance requirements or as per agreed contractual terms.

6.2 Protection against Malicious Software Before any software or development services are acquired for a UCSF managed device that has access to proprietary or confidential information, due diligence must be performed to ensure that the vendor or source is reputable, reliable, and financially viable. A thorough product evaluation, and where applicable, product source code inspection should be conducted before software is placed into operational use. All UCSF managed Microsoft Windows devices must use IT Security Team approved, up to date anti-virus software. Anti-virus software must be continuously enabled and set to actively scan for viruses whenever a program or e-mail attachment is executed and perform a full system scan at minimum weekly intervals.


17

6.3 Housekeeping

6.3.1 Information Back-up All critical UCSF server software must be copied, to the extent permitted by the software license or contract, prior to its initial usage, and such copies must be stored in a safe and secure location. These master copies must not be used for ordinary business activities, but must be reserved for recovery from computer virus infections, hard disk crashes, and other computer problems. All critical information and critical software resident on UCSF managed computer systems must be backed-up with at least two recent and complete backups (not incremental backups) made on different dates and must be stored in an environmentally-protected and access-controlled site that is far enough away from the originating facility to escape a local disaster.

6.3.2 Problem Tracking and Maintenance Logs Operational and support staff must maintain a log of their activities such as system starting and finishing times, introduction and use of special jobs or data files, system errors and corrective action taken, confirmation of handling files and output, and name of person making the log entry. Problem tracking logs must be maintained for UCSF managed production systems with at least monthly reporting to systems and business management. Maintenance logs must be maintained for UCSF managed production systems with at least monthly reporting to systems and business management.

6.4 Systems Management

6.4.1 System Controls Develop configuration standards which address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Establish a process to identify newly discovered security vulnerabilities and update configuration standards to address new vulnerability issues. Implement only one primary function per server. Disable all unnecessary and insecure services and protocols. Configure system security parameters to prevent misuse. Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

6.4.2 Encryption Controls When encryption is implemented it must meet the following minimum key bit requirements:

• 80 bits for secret key based systems (for example 3DES) • 1024 bits modulus for public key algorithms based on the factorization (for example, RSA) • 1024 bits for the discrete logarithm (for example, Diffie-Hellman) with a minimum 160 bits size of

a large subgroup (for example, DSA) • 160 bits for elliptic curve cryptography (for example, ECDSA)

Protect cryptographic keys used for encryption of proprietary or confidential information against both disclosure and misuse:


18

• Restrict access to keys to the fewest number of custodians necessary • Store keys security in the fewest possible locations and forms. • Generate strong cryptographic keys • Secure the key storage location • Periodically change the cryptographic keys when possible at least annually. • Retirement or replacement of old or compromised keys • Use split knowledge when possible during the establishment of keys • Prevent unauthorized substitution of keys

6.5 Network Management

6.5.1 Network Controls All UCSF managed servers and devices that are accessible via public networks must be placed on subnets separate from internal networks, known as DMZ’s, and must be protected and secured by properly configured firewalls, and appropriate access control methods. A stateful inspection firewall is to be implemented between all un-trusted networks and UCSF networks containing confidential information. Document the firewall and router services, protocols, ports, and business justification necessary for business. Restrict inbound and outbound traffic to that which is necessary for networks containing or transmitting confidential information. Limit inbound Internet traffic to addresses within a DMZ. Do not allow any direct routes inbound or outbound for traffic between the Internet and the cardholder data environment. Do not allow internal addresses to pass from the Internet into the DMZ. Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses internally or within the DMZ. Implement NAT, PAT, or IP masquerading to prevent internal addresses from being revealed on the Internet. Router configuration files are to be secure and synchronized (running configuration and start-up configuration have the same secure configurations). For each physical UCSF facility, a current inventory of connections to external networks, including telephone networks, extranets, and the Internet will be maintained. Internal and external network vulnerability scans are to be run at least quarterly and after any significant change in the network. Perform an external and internal penetration test at least once a year. The test must include network-layer and application-layer penetration tests. Use intrusion detection systems and/or intrusion prevention systems to monitor all traffic in networks containing or transmitting confidential information. Wireless connectivity is not allowed to be directly connected to UCSF ’ internal network it must be logically separated with a stateful inspection firewall that blocks all access to and from trusted networks.


19

Wireless data transmissions must provide WPA2 or better encryption and includes the appropriate access control methods defined by a risk analysis performed by the UCSF Networking team. Quarterly scans for the presence of unauthorized wireless access points must be done. All external connections to the network are reviewed at least annually for continued compliance. A review of all UCSF managed firewall and router rule sets must be performed at least every six months.

6.6 Computer Media Handling and Security

6.6.1 Management of Storage Media All storage media should be stored in accordance with the manufacturer’s specification. Removable media containing confidential or proprietary information must be secured to protect against accidental or intentional loss, manipulation, or compromise at all times. Such computer media must be stored in a physically controlled location where access is limited. If any removable media is transported to and from off-site locations, transportation procedures must be created and approved by the IT Security team. Once approved these procedures must be adhered to by any individual handling the media. These procedures must at a minimum describe how the media is being delivered to and from the off-site location, who is authorized to access and handle the media, and what security safeguards have been deployed. A tracking log must be created and maintained to record the movement of media to and from off-site locations. The log must also show proper management authorization of the movement.

6.6.2 Disposal of Data and Storage Media The information created and stored by any of UCSF managed systems will be retained for a minimum period of six year or whatever timeframe meets both regulatory and/or business associate/partner contractual requirements. Any proprietary or confidential information in the form of voice recordings will be retained for a period predefined by business associate/partner contracts. The Data Destruction Policy applies to any Removable Electronic Media; includes but is not limited to read-only and read-and-write disks, compact disks (CDs), digital video disks (DVDs), flash memory devices; secure digital (SD) cards, backup tapes, and faxes. After information has reached end of its required retention period, all PHI, cardholder information and personally identifiable information shall be immediately and securely destroyed. To ensure the proper destruction of sensitive information (i.e. e-PHI, EMR, and/or Cardholder information) the Information Technology Department will utilize as appropriate one or more of the following methods of destruction:

• Deleting on-line data using the appropriate utilities; • “Degaussing” {removing or neutralizing the magnetic field} computer tapes to prevent recovery of

data; • Removing CHD/PII and/or e-PHI from disc drives being sold or replaced, using the appropriate

utilities; • Zero-ing out hard drives as per DOD instructions • Erasing discs or other storage devices to be re-used using a special utility to prevent recovery of

data; or • Destroying discarded discs or other storage devices.

To ensure that all pertinent information is properly recycled, the Information Technology Department shall carry out the destruction of all e-PHI, EMR, and/or Cardholder information. Upon completion of the


20

destruction/disposal, a record/log will be generated and retained as per internal data retention policy. This record will contain the following information: - Date of destruction; - Method of destruction; - Description of the dosed records; - Inclusive dates covered; - A statement that the records have been destroyed in the normal course of business; - The signatures of the individuals supervising and witnessing the destruction; Important: If carried out by a third party:

• The data destruction shall be completed onsite in presence of a data custodian representative (Organization employee).

• In case of the destruction of Protected Healthcare Information, PII (personally identifiable information) and/or cardholder information an official statement of destruction shall be provided and kept always available for the entitled entities verification.

6.6.3 Data Retention The information created and stored by any of UCSF managed systems will be retained for a minimum period of six year or what meets both legal and/or business requirements. Any proprietary or confidential information in the form of voice recordings will be retained for a period predefined by client business contracts. Once the data retention period has been reached for specific information the destruction of the information will be carried out using the policies and procedures defined for proper disposal of data and storage media.

6.7 Exchanges of Information and Software

6.7.1 Information and Software Exchange Agreements Formal software agreements, including software escrow agreements, must be established prior to the exchange of information and software between UCSF and external organizations.

6.7.2 Security of Data and Computer Media in Transit All data classified as confidential and personal information must be encrypted using an IT Security Team approved encryption method before being transmitted on an un-trusted or public network such as the Internet. All data classified as confidential and personal information that cannot, for whatever reason, be encrypted, should be hand delivered or sent by overnight courier rather than transmitted on the network.

6.7.3 Electronic Commerce Security Adequate protection as defined by IT Security Team, including authentication, authorization, and non-repudiation, must be provided to protect all e-commerce transactions against network threats, which may result in fraudulent activity, contract date, and disclosure or modification of information. Do not store on any UCSF managed device the full contents of any track from the magnetic stripe (located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. Do not store on any UCSF managed device the card-verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions. Do not store on any UCSF managed device the personal identification number (PIN) or the encrypted PIN block.


21

Mask the Primary Account Number (PAN) when displayed on any UCSF managed device. The first six and last four digits are the maximum number of digits to be displayed. Render PAN, at minimum, unreadable anywhere on any UCSF managed device where it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography; • Truncation; • Index tokens and pads (pads must be securely stored); • Strong cryptography with associated key-management processes and procedures.

Never send unencrypted PANs by end-user messaging technologies (for example, e-mail, instant messaging, and chat).

6.7.4 Other Forms of Information Exchange Security controls must be properly identified and put in place to protect information exchange through the use of voice, facsimile, video communications, and similar technologies. The IT Security team must approve all other external network communication methods and external information exchange methods not previously stated, including remote control software, online collaboration tools, and peer-to-peer mediums.


22

SECTION 7 System Access Control Objective: The objective of this statement is to minimize the risk to UCSF information assets arising from unauthorized or inappropriate UCSF managed network, system, and application access. Scope: This statement defines the parameters for securely accessing UCSF information system resources based on the employees need to know and the sensitivity of the information. Owner: IT Security Team

7.1 Business Requirements for Access Control All UCSF facilities must adhere to formal Access Control procedures based on “principle of least privileged” Access. These procedures will define an employee’s level of access to various profiles for common categories of jobs, responsibilities, and business needs, thus making them a user of various systems, procedures, and tools. Hereafter the term “user” will refer to the access granted to that employee. Access control systems must be set to “deny all” unless specifically allowed.

7.2 User Access Management

7.2.1 User Registration & Revocation All UCSF facilities must follow the formal user registration and rights revocation procedure for the timely granting and removing access to all information systems. Users must be assigned an ID and password that is unique to them and not shared. All user IDs will be disabled after 90 days of inactivity. Accounts used by vendors for remote maintenance should only be enabled for the time period necessary.

7.2.2 Privilege Management Privileged accounts require additional controls to prevent misuse. Formal procedures for granting access to, using, and tracking privileged accounts must be documented and enforced. The authorization form requesting access and specifying privileges must be signed by management.

7.2.3 User Password Management Passwords issued by a system administrator must force the user to choose another password before the logon process is completed. Passwords must not be stored in readable form in databases, batch files, automatic login scripts, software macros, terminal function keys, in computers without access control systems, or any location where unauthorized individuals might discover them. Passwords must be changed immediately if the user account is compromised or the password is disclosed. A user’s identity must be verified before their password is reset. The display and printing of passwords by information systems must be masked, suppressed, or otherwise obscured so nobody other than the owner of the user ID and password will be able to observe or discover them.


23

Where possible, information systems must require passwords to be a minimum of eight characters in length and contain at least one lowercase letter, uppercase letter, and one number, be changed at least every 90 days, and not be reused for at least five password generations. Repeat access attempts are to be limited to five before the account is locked out for a minimum duration of thirty minutes.

7.2.4 Review of User Access Rights System access privileges granted to every user must be reevaluated by the system owner or the user’s direct supervisor at least annually to determine whether the current enabled system privileges are necessary to perform the user’s current job duties.

7.3 Process Account Management Any process accounts used for system services, batch processes, login scripts, and/or application interactions must have additional controls including complex passwords, location restrictions, and time restrictions. The system owner and IT Security Team must re-evaluate process accounts at least annually to determine whether currently enabled system privileges are needed and the process account is still valid.

7.4 Network Access Control All perimeter network devices used to provide connectivity to a third party or the public Internet must be configured to deny all connections except those used for primary business and support purposes. When access is requested that requires changes to perimeter devices outside of the normal operating standards, the connection type and method must be reviewed and approved by the IT Security Team. All perimeter network devices connected to the public Internet must at a minimum prevent UCSF’s network from being used as a directed broadcast amplifier, block all RFC 1918 private internet addresses from entering the network, and prevent spoofed source addresses from entering and leaving the network. Access to maintenance ports must be protected by physical and procedural control mechanisms. The IT Security team must approve all requests for diagnostic port access in advance of any connection rights being granted to hardware or software support personnel. Access rights for Non-UCSF entities may only be granted for a limited term and must be immediately removed when the support activities are completed.

7.5 Operating System Access Control

7.5.1 System Log-on Procedures All systems must activate an automatic ID suspension following three unsuccessful attempts. All information systems must display the following disclosure and warning banner at the start of each network and system session “WARNING:Thissystemisfortheuseofauthorizedusersonly.Individualsusingthiscomputersystemwithoutauthorityorinexcessoftheirauthorityaresubjecttohavingalltheiractivitiesonthissystemmonitoredandrecordedbysystempersonnel.Anyoneusingthissystemexpresslyconsentstosuchmonitoringandisadvisedthatifsuchmonitoringrevealspossibleevidenceofcriminalactivity,systempersonnelmayprovidetheevidenceofsuchmonitoringtolawenforcementofficials.”

7.5.2 User Identification and Authentication All systems containing access to restricted, confidential and personal information assets must require users to log on and authenticate (i.e., supply their own unique user ID and password) to the system before permitting them access to system resources. Always change vendor-supplied defaults before installing a new device on the network. This includes things such as passwords, SNMP community strings, and the elimination of unnecessary accounts.


24

7.5.3 Use of System Utilities Access to system and network administrative utility programs must be restricted, and the use of those programs must be controlled and monitored.

7.5.4 Session Time Out Computing systems must disable a user session after a reasonable period of inactivity. LAN workstations and desktop computer systems must activate a screensaver or workstation lock after a maximum of 15 minutes of inactivity. When a user leaves their workstation unattended they are to ‘lock’ the workstation to prevent unauthorized access.

7.6 Monitoring System Access and Use

7.6.1 Event Logging The logging capabilities of every system must be evaluated and a determination must be made by the system owner, in conjunction with the IT Security, regarding the best logging strategy to use for the system. Event logging must be activated on every system and device to capture and retain, at a minimum, access attempts, process exceptions, configuration changes, and other security related events to an event log. Event logs must be retained, in compliance with record retention policies, and regularly reviewed for the presence of security anomalies. Audit history is to be retained for at least one year, with a minimum of three months immediately available for analysis. Record at least the following audit trail entries for all system components that handle confidential information:

• User identification • Type of event • Date and Time • Success or failure indication • Origination of event • Identity or name of affected data, system component, or resource

7.6.2 Monitoring System Use All information systems must employ the active, continual use of monitoring controls. Each system owner is responsible for ensuring that the system and application logs are reviewed on a regular basis. All event logs and reports generated out of system monitoring activities are to be handled as confidential information and secured from unauthorized access. Audit trail files are to be backed up to a centralized log server or to media that is difficult to alter. External-facing technologies are to write logs to a log server on the internal LAN. File-integrity monitoring is to be used on systems where risk and compliance deems it necessary.

7.6.2.1 Logging and Reviewing Events The responsibility for reviewing logs for access violations must incorporate segregation of duties. Access to logging facilities must be controlled to protect log information from both intentional tampering and operational errors. Logs for systems that perform security functions should be reviewed daily.

7.6.3 Clock Synchronization All information systems must ensure that system clocks are accurate and regularly synched to an agreed-upon and documented standard such as UCT (Universal Coordinated Time).


25

7.7 Mobile Computing / Remote Access

7.7.1 Mobile Computing No unauthorized software, hardware or telecommunications device, as determined by the IT Security team, may be installed on or connected to the UCSF managed communications networks, computers, terminals, or lines. Mobile-computing devices must consistently employ logon protection via password, and file access controls that adequately protect the mobile computing resource and information accessed or stored on the device. All mobile computing equipment that connects to UCSF managed networks must adhere to the controls set forth in this policy including anti-virus software, hardware or software firewalls, and other controls as required to comply with this document. Mobile computers that connect to the Internet must have a personal firewall activated. .

7.7.2 Remote Access Prior approval from the IT Security team is required before remote access will be granted to UCSF enterprise data networks and information resources. All inbound user VPN access through a public or external network to UCSF computers and systems requires user or node identification and must employ two-factor authentication. All remote access accounts must be assigned to an individual. Prior to gaining network access, all contractor, third-party/vendor, and temporary employees must provide the appropriate Management with a list of the UCSF network resources they require access to, including network addresses, network protocols being used, and the time of day access is required. Remote-access technologies for vendors are only to be activated when needed by vendors, with immediate deactivation after use. If cardholder data is accessed via remote-access technologies, prohibit copy, move, and storage of cardholder data onto local hard drives and removable electronic media.


26

SECTION 8 System Development and Maintenance Objective: This statement addresses the process by which UCSF managed computer systems are acquired, developed and maintained within the organization. Scope: The objective of this statement is to ensure that security is built into UCSF information systems. Owner: PCI Oversight Committee

8.1 Security Requirements of Systems System security requirements must be identified, defined, and implemented as part of an overall system development life cycle that includes system specifications, design, testing, training, and formal application approval by the designated system owner. All system security requirements and back out procedures must be identified during the requirements phase of any project and must be justified, documented and agreed upon by the application’s business owner in advance of development work beginning on the system.

8.2 Security in Application Systems The IT Security Team will perform a risk assessment to determine the level of security controls, audit trails, and activity logs that must be included in the design and built into the application system.

8.2.1 Input Data Validation All transactions to be input to a multi-user production computer system must be subjected to input validation checks. Design and development of these validation checks are the responsibility of the application business owner. Procedure and controls must be defined to handle transactions that fail such checks. Resubmitted transactions must be subjected to the same validation procedures that original input transactions receive.

8.2.2 Control of Internal Processing Data integrity checks must be incorporated into systems to prevent and detect intentional or accidental data corruption. Application systems must be designed to minimize the risk of processing failures by implementing security controls to prevent programs running in the wrong order or after the failure of a prior process. Application systems must provide processes or routines for responding to system failures.

8.2.3 Output Data Validation Data generated by application systems must be validated to ensure that the processing of stored information is correct and appropriate prior to use or transmission.

8.2.4 Code Review Custom code for systems that contain confidential information must go through code review to identify any potential coding vulnerabilities before release to production.

8.2.5 Secure Coding Develop all web applications incorporating the Open Web Application Security Project (OWASP) secure coding practices (or any other industry best practices development methodology) to protect against:

• Cross-site scripting (XSS) • Injection Flaws such as SQL Injection • Malicious file execution


27

• Insecure direct object references • Cross-site request forgery (CSRF) • Information leakage and improper error handling • Broken authentication and session management • Insecure cryptographic storage • Insecure communications • Failure to restrict URL access

8.2.6 Application Security Vulnerability Assessments Review all public-facing web applications via manual methods or automated application vulnerability security assessment tool methods at least annually and after changes.

8.3 Cryptographic Controls Cryptographic controls that conform to the requirements set forth in Section 6.4.2 must be used for the protection of restricted, confidential and personal information for which other controls do not provide adequate protection.

8.4 Security of System Files

8.4.1 Control of Operational Software The IT development team must provide a documented procedure for promoting applications to production status. The IT application development team will not move any software into the production environment without following an approved authorization process defined by IT Management. Application software in development and testing must be kept separate from production application software. This separation must be achieved via physically or logically separate computer systems with access controls. There must be clear separation of duties between development, test, and production environments. The IT team must have a documented patch management process for ensuring that vendor updates are applied in a regular and timely fashion. This patch management process must clearly outline the timeframe between patch release from the vendor and integration into UCSF managed systems as well as the responsible parties involved. Testing of all security patches and configuration changes must be done before deployment. This testing must include at minimum:

• Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.) • Validation of proper error handling • Validation of secure cryptographic storage • Validation of secure communications • Validation of proper role-based access control

Critical security vulnerability patches must be installed within a month from release.

8.4.2 Access Control to Program Source Library Access to program source libraries must be controlled, and program source code must be maintained in a secure non-production environment. Security controls must be implemented to safeguard production and test data and prevent the inappropriate copying of program source code and data.

8.4.3 Protection of System Test Data The use of test data containing proprietary or confidential information should be avoided. When proprietary or confidential information is used in testing, appropriate controls must be implemented to adequately protect the data and any output generated from testing. Test data and accounts must be removed before systems are deployed in production.


28

8.5 Security in Development and Support Processes

8.5.1 Integration Management The IT Systems team must implement a documented procedure for installing and updating information systems that includes capacity planning, security controls, monitoring, system configuration baselines, and ensures that current systems will not be adversely affected.

8.5.2 Outsourced Software Development Third parties who develop software for UCSF must be bound by a contract that includes, but is not limited to, clear and distinct definition of licensing arrangements, quality and accuracy expectations, system acceptance criteria, escrow arrangements, auditing privileges and procedures, and testing requirements. UCSF PCI Oversight Committee must review all outsourced software development contracts.


29

SECTION 9 Business Continuity Management Objective: The objective of this statement is to mitigate the impact of various types of failures or disasters on business processes. Scope: This statement covers UCSF approach and commitment to Business Continuity Management. Owner: PCI Oversight Committee

9.1 Aspects of Business Continuity Management All UCSF facilities will have a documented Business Continuity Management program that includes preventative and recovery controls to promote an acceptable level of business recovery in the case of a business disruption. This program must be tested and updated at least annually in order to maintain its effectiveness.

9.2 Business Continuity Plan (BCP)The Business Continuity Management program must include a Business Continuity Plan to restore and recover business processes after an interruption. These plans must be based upon a Business Impact Analysis (BIA) and a risk analysis performed by the responsible BCP Project Manager, in order to understand the business priorities and their impact on the business.

9.3 Disaster Recovery Planning (DRP) The Business Continuity (BC) Management program must include a Disaster Recovery Plan (DRP) to restore and recover the technology infrastructure. The Disaster Recovery Plan shall mirror and complement the requirements of the BCP. All DR associated activities will be carried out in a highly secure manner. During emergency, in addition to official emergency teams (fire squad police and EMR unit(s)), only a limited number of Organization’s employees shall have access to the facility and have the ability to work on Organization’s systems and infrastructure. The employees having access to the facility are part of the designated UCSF ERT (emergency response team) and have the highest access clearance, however not all these employees will be able to access all the sensitive information. The team will ensure that 24-hour physical monitored access by at least one team member will be in place until full operational capacity is restored to ensure that access to sensitive information such as but not limited to e-PHI, EMR, PII and cardholder information shall always be monitored, restricted and the access to this information shall be allowed only to those employees that have previously been verified and approved.

9.4 Life / Health Safety (LHS) The Business Continuity Management program must incorporate a Life / Health Safety Plan to deal with employee health and safety in the event of a disaster or other emergency.

9.5 Risk Management (RM) The Business Continuity Management program should consult UCSF Risk Management and Insurance Services to develop risk mitigation methods to protect against financial and property loss due to an interruption.


30

9.6 Responsibilities Each UCSF Unit Department Official or designee will review the BCP and agree in writing at least annually that the plan is adequate for the business at the facility.


31

SECTION 10 Compliance Objective: The objective of this statement is to meet regulatory and legal obligations by ensuring sufficient compliance with the Information Security Policy. Scope: This statement covers compliance with legal and other regulatory requirements in relation to Information Security. Owner: PCI Oversight Committee

10.1 Compliance Information systems must meet applicable legal, regulatory, contractual, and UCSF security policies, standards, procedures, and other security requirements.

10.1.1 Identification of Applicable Legislation Specific controls and responsibilities must be defined and documented for information systems that are impacted by legal, regulatory, contractual, and UCSF security policy requirements.

10.1.2 Safeguarding of Organizational Records Important data and records must be protected from unauthorized and unwarranted manipulation, loss, and destruction. Appropriate retention time periods must be followed as defined by the PCI Oversight Committee. Data storage systems must be maintained such that required data can be retrieved in an acceptable timeframe and manner.

10.1.3 Data Protection and Privacy of Personal Information Compliance with applicable Data Protection and Privacy Procedures is the responsibility of the data owner. All individuals covered by this policy are responsible for identifying Privacy Regulations applicable to their daily job function and following any processes and procedures that measure and ensure compliance with regulations.

10.2 Reviews of Security Control Requirements and Compliance The security of information systems and associated facilities must be consistently monitored and regularly reviewed to ensure compliance with appropriate security policies, standards, procedures, and other security requirements. Each individual that is in a leadership position with UCSF is responsible to ensure that security procedures within their area of responsibility are carried out correctly and in compliance with appropriate security policies, standards, procedures, and other security requirements.

10.3 System Audit Controls Audit requirements and activities involving checks on operational systems must be carefully planned and agreed upon in advance to minimize the risk of disruptions to business processes. Information produced as a result of a system audit must be managed and handled as confidential information. UCSF information system audits may not be shared outside of normal operating channels without the consent of the PCI Oversight Committee.


32

APPENDIX A. Glossary of Terms TERMS: DEFINITION: BroadcastAmplifier A broadcast amplifier is a system that will take a

single ICMP Echo Request and respond with one echo for each host on the network at the time of receiving the request.

BusinessContinuityManagement An ongoing program supported and funded by executive staff to ensure business continuity requirements are assessed, resources are allocated and, recovery and continuity strategies and procedures are completed and tested.

CardholderDataEnvironment Area of computer system network that possesses cardholder data or sensitive authentication data and those systems and segments that directly attach or support cardholder processing, storage, or transmission. Adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from those that do not, may reduce the scope of the cardholder data environment and thus the scope of the PCI assessment.

CryptographicControls Systems controls or functions that encrypt a

message in such a way that anyone who intercepts the message cannot understand it

DataIntegrityChecks The process of checking data to ensure that it is not been modified from its original or intended state.

Encryption Cryptographic transformation of data (called "plaintext") into a form (called "cipher text") that conceals the data's original meaning to prevent it from being known or used.

ElectronicProtectedHealthInformation(EPHI)

Is patient health information which is computer based, e.g., created, received, stored or maintained, processed and/or transmitted in electronic media.

IntegrationManagement The process and procedures necessary to ensure that all proposed system or application changes are reviewed to verify that they do not compromise or negatively impact the functionality and security of other systems or the operating environment.

MaintenancePort A maintenance port is a dedicated port or access mechanism used to administer or support a device or system.

PrincipleofLeastPrivileged The principle of least privileged requires that each process or user be granted the most restrictive set of privileges needed for the specific task.


33

PrivilegedAccount A system account with root, administrator, or supervisor equivalent access rights to system resources.

ProcessAccount Process accounts are User ID’s used to facilitate automated system processes or services. Such accounts as the name implies are associated with processes rather than with individuals

RFC1918PrivateAddress IANA has set aside three address ranges for use by private or non-Internet connected networks. This is referred to as Private Address Space and is defined in RFC 1918. The reserved address blocks are: 10.0.0.0 to 10.255.255.255 (10/8 prefix) 172.16.0.0 to 172.31.255.255 (172.16/12 prefix) 192.168.0.0 to 192.168.255.255 (192.168/16 prefix)

Two-factorAuthentication Two-factor authentication is based on something a

user knows (factor one) plus something the user has (factor two). In order to access a network, the user must have both factors-just as he/she must have an ATM card and personal identification number (PIN) to retrieve money from a bank account. In order to be authenticated during the challenge/response process, users must have this specific (private) information.

UTC UTC refers to a time scale called "Coordinated Universal Time" (abbreviated UTC), which is the basis for the worldwide system of civil time. This time scale is kept by time laboratories around the world, including the U.S. Naval Observatory, and is determined using highly precise atomic clocks.

InputValidationChecks The process of checking input data to ensure that it is complete, accurate, and reasonable.

Documents

UCSF 650-16 Addendum E - PCI · 2020. 5. 19. · • To comply with data security requirements defined by Payment Card Industry Data Security Standards 3.1/3.2 (PCI-DSS) Scope: The