Information Security Policy Glossary
Below are definitions of key terms used in UC Berkeley's Information Security Policies. For a list of all policies, visit our A-Z Policy Catalog
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
Term |
Definition |
|
See “Unit Head” |
|
|
See “Service Manager” |
|
|
A term used to collectively refer to IT Resources and Institutional Information (both defined in this glossary). |
|
|
The process of verifying that an individual, entity, or application is who, or what, it claims to be. For example, this might involve validating personal identity documents, requiring a username and passphrase, biometric verification, or verifying the authenticity of a website with a digital certificate. |
|
|
The degree to which Institutional Information and IT Resources must be accessible and operational to meet business needs. All UC Institutional Information and IT Resources are classified into one of four Availability Levels based on the level of business impact their loss of availability or service would have on UC, with A4 causing the highest level of impact and A1 causing a minimal level of impact. |
|
|
See “Institutional Information” |
|
|
See “IT Resources” |
|
|
UC Berkeley |
|
|
The Chief Information Officer (CIO) is the senior executive responsible for information technology or information system functions throughout Campus. |
|
|
The Chief Information Security Officer (CISO) is the role responsible for security functions throughout Campus, including assisting in the interpretation and application of information security policies. |
|
|
A cloud service is any service that is hosted remotely and provided over the Internet. For the purposes of UC Berkeley’s Minimum Security Standards (MSSND and MSSEI), a cloud service refers to any service hosted at a non-Campus location. |
|
|
The Cyber-risk Responsible Executive (CRE) is an individual in a senior management or academic position who reports to the chancellor or top Campus executive. The CRE is accountable for all information risk assessments, security strategies, planning and budgeting, incident management, and information security implementation. |
|
|
1. IT Resources that manage unrelated sets of Institutional Information or sets of large or particularly sensitive Institutional Information. 2. IT Resources that meet two conditions: a) Several information systems rely on the resource such that a security issue with the resource would affect multiple systems. b) The default or standard method for securing the system is inappropriate due to an elevated level of risk, complexity, or the specialized nature of the IT Resource |
|
|
See “Service Provider” |
|
|
Data Loss Prevention (DLP) is a type of network monitoring that focuses on automated inspection of content to identify and block exfiltration, leakage, or loss of confidential information. At UC Berkeley, DLP is strictly regulated by campus information security and privacy governance and the UC Electronic Communications Policy. |
|
|
See "Institutional Information Proprietor" |
|
|
Software installed on workstations, laptops, and servers (endpoints) designed to address sophisticated or advanced persistent threat (APT) attacks with features beyond traditional malware protection capabilities, plus (for UC Berkeley) remote forensics abilities. Like anti-malware software, EDR software runs in the background while you do your normal work. What's unique about EDR software (compared to other malware or antivirus programs) is that it uses real-time intel in conjunction with machine learning to quickly detect threats and immediately act to mitigate/block any damage. Additional, Berkeley-specific information about EDR. |
|
|
See "Information Security Event" |
|
|
Student records protected under the Federal Family Educational Rights and Privacy Act of 1974 (FERPA) include, but are not limited to:
Student records are generally classified as Protection Level 3 (P3). See the Data Classification Policy for details and exceptions. UC Berkeley’s Office of the Registrar is the campus authority for FERPA. |
|
|
(sometimes called a shared account) An account that can be accessed by multiple individuals to allow them to appear as a single business entity or accomplish a single shared function (e.g., “physics department” or “chancellor’s office"). SPAs are Functional Accounts. Auto logon systems that automatically log users in (e.g., kiosk1, guest1, etc.) should also be treated as functional accounts. |
|
|
Information classified at Protection Level 4 (P4) |
|
|
See "Information Security Incident" |
|
|
An account that is under the control of a specific individual and is not accessible to others. |
|
|
Workstations, laptops, tablets, smartphones, and other electronic devices and equipment that are under the control of a specific individual and not accessible to others. Also includes shared machines that are accessible to multiple people but generally only in use by one person at a time and don't meet the definition of "IT Infrastructure," such as lab workstations, hoteling workstations, check-out equipment, etc. |
|
|
Data which is defined as an individual’s own personal information that is not considered "Institutional Information" |
|
|
Known informally (and historically) as "Security Contact". An Information Security Contact is a group of individuals who have been designated to receive and respond to security notices from UC Berkeley’s Information Security Office (ISO) for their department or for a specific set of IT Resources. Information Security Contacts must be associated with a Campus org node that rolls up to a Unit. They are accountable to their Unit Information Security Lead(s) |
|
|
An identified occurrence in a process, system, service or network state indicating a possible breach of information security policy, a possible breach of privacy policy, a failure of controls or a previously unknown situation that may be relevant to security. This also includes alerts and notifications. This definition is from the UC Information Security Incident Response Standard. |
|
|
A compromise of the confidentiality (privacy), integrity or availability of Institutional Information in a material or reportable way, whether caused by unauthorized action or accident. (2) A single event or a series of unwanted or unexpected Information Security Events that have a significant probability of compromising business operations or threatening information security. Incidents are also called IT incidents, computer incidents, cyber incidents or security incidents. This definition is from the UC Information Security Incident Response Standard. |
|
|
University of California |
|
|
|
|
A term that broadly describes all data and information created, received and/or collected by UC relating to the activities or operations of the university, regardless of where the data is stored. Institutional Information does not include Individually-Owned Data. |
|
|
The individual, group, committee, or board responsible for the Institutional Information and processes supporting a University function. Proprietor responsibilities include, but are not limited to: ensuring compliance with University policy regarding the classification, protection, access to, and release of information according to procedures established by UC, the Location, or the department, as applicable to the situation. Proprietors are also responsible for ensuring compliance with federal or state law or regulation. |
|
|
As used in the context of UC Berkeley's Minumum Security Standards for Electronic Information (MSSEI): Servers (i.e., devices that provide access to data from other devices, or that provide a service), bastion hosts, back-up and storage systems, network appliances, life safety systems, cloud infrastructure, and any systems that provide authentication, authorization or configuration management for those systems – whether physical or virtual, on premise or in the cloud, owned/managed by an IT or non-IT unit. |
|
|
A term that broadly describes IT infrastructure, software, and/or hardware with computing and networking capability. This includes:
|
|
|
The individual responsible for the IT Resources and processes supporting a University function. Proprietor responsibilities include, but are not limited to: ensuring compliance with University policy regarding the classification, protection, access to, location, and disposition of IT Resources. Proprietors are also responsible for ensuring compliance with federal or state law or regulation. |
|
|
See “Service Provider” |
|
|
A Workforce Member who is assigned specific information technology (IT) duties or responsibilities. This applies to individuals working for the university in any capacity, whether paid or unpaid, including student employees, volunteers, and contingent workers. |
|
|
Information classified at Protection Level 2 (P2) |
|
|
Information classified at Protection Level 1 (P1) |
|
|
Information classified at Protection Level 3 (P3) |
|
|
See “Statutory Requirement for Notification” below. |
|
|
A passphrase is a type of password. They are generally longer than a traditional password and can contain spaces in between words such as: "This May Be One Way To Remember". Like a traditional password, a passphrase can also contain numbers and symbols, and does not have to be a proper sentence or grammatically correct. Traditional passwords generally do not have spaces while passphrases often have spaces and are longer than a typical random string of characters |
|
|
Academic Personnel Records include, but are not limited to: confidential academic review records, non-confidential academic review records and "personal" information (as defined in Section 160 of the Academic Personnel Manual [PDF]). Staff Personnel Records (listed in Section 80 of the Personnel Policies for Staff Members) include, but are not limited to:
Academic and staff personnel records are generally classified as Protection Level 3 (P3). See the Data Classification Policy for details and exceptions. |
|
|
Any device where credentials are used to provide privileged access (superuser, root, administrator, database administrator, or equivalent) to an institutional device. Physical, logical, and virtual devices included. |
|
|
An account used to configure or significantly change the behavior of a computing system, device, application or other aspect of the IT Resource or IT infrastructure. Privileged accounts include, but are not limited to, local administrator accounts, UNIX “root” accounts, Windows Administrator accounts, and device configuration accounts. |
|
|
See “Institutional Information Proprietor” or “IT Resource Proprietor” as applicable. |
|
|
A general term used to refer to information classified at Protection Level 2 (P2) or higher. |
|
|
Information systems that handle, store, or transmit institutional data restricted by laws and policies, or that handle institutional data classified as P2 or higher as defined by the Berkeley Data Classification Standard |
|
|
An assigned number representing the level of protection needed for Institutional Information or an IT Resource. The scale goes from the minimum level of protection (Protection Level P1) to the highest level of protection (Protection Level P4) and is based on the potential harm resulting from unauthorized access, disclosure, loss of privacy, compromised integrity, or violation of external obligations. |
|
|
See “Service Provider” |
|
|
Information which may be disclosed to any party without the prior consent of the individual to whom the information pertains. This includes the following for academic and staff personnel, and students: “Non-Personal” Academic Personnel Information as defined by APM-160
Student Directory Data (unless the student has requested that such information not be disclosed)
|
|
|
Information intended to be available to the public with no access restrictions |
|
|
An assigned number representing the urgency to restore the availability or functionality of Institutional Information or IT Resources after a disaster or disruption. The scale goes from the minimum level of urgency, Recovery Level RL1, to the highest level of urgency, Recovery Level RL5. Recovery Level is formally defined in IS-12, UC's Systemwide IT Recovery Policy (Sec 4.2). At UC Berkeley, Recovery Levels are identified in partnership between the IT Resource Proprietor(s) and the Service Provider, and are based on the functional requirements of the service. |
|
|
The length of time allowed to restore business processes to a defined level of service following a disruption. |
|
|
UC faculty members, students or affiliates, including Principal Investigators, conducting research on behalf of UC. A Researcher is also a Workforce Member. |
|
|
See “Service Provider” |
|
|
See “IT Resource Proprietor” |
|
|
Risk acceptance is the process of deciding whether a risk is within the tolerances acceptable to an organization. This determination must take into consideration both the likelihood and impact of a negative event, the combination of which represents the “risk". In the context of information security, impacts may include:
Risk acceptance is one component of risk management, along with risk avoidance, risk mitigation, risk sharing, and risk transfer[1], and must occur at the level of campus authority that matches the potential risks. [1] NIST SP 800-39, Sec 3.3 (Activities, Task 3-1) |
|
|
See “Information Security Contact” |
|
|
See “Unit Information Security Lead” |
|
|
As used in the context of UC Berkeley's Minumum Security Standards for Electronic Information (MSSEI), a service is defined as software or a program that is network accessible. Examples include web, database, cloud-based, and mobile applications. |
|
|
Accounts intended for automated processes such as running batch jobs or applications. |
|
|
A Service Manager has overall accountability for defining a service, application, or system, ensuring services are delivered in accordance with agreed business requirements, and managing the service lifecycle. |
|
|
Any UC group or organization providing IT services to one or more campus Units, including their own Unit. Synonyms: Data Custodian, Resource Custodian, Provider |
|
|
See "Functional Account" |
|
|
If a data or system compromise would cause further and extensive compromise from multiple (even unrelated) sensitive systems, the data or system creating this "shared-fate" warrants an elevated Protection Level of P4. |
|
|
Also known as "notice-triggering" information. California State Civil Code 1798.29, other U.S. laws such as the Health Insurance Portability and Accountability Act (HIPAA), various international laws, as well as some data use agreements, regulations, and other external requirements, require notification to individuals and/or government agencies in the event of a security breach of certain personal information. Examples of notice-triggering information from California State Civil Code 1798.29, linked above, include:
Questions about whether information would be considered notice triggering should be referred to the campus Privacy Office: privacyoffice@berkeley.edu. * California State Civil Code 1798.29 applies to personal medical information and personal health insurance information even under circumstances not covered by HIPAA. See section (h) for definitions under this law. Genetic data, as it applies to this law, is also defined in section (h). |
|
|
An external, third-party entity that provides goods or services to UC. These goods and services can include consulting services, hardware, integration services, software, systems, software-as-a-service (SaaS) and other cloud services. Non-UC entities that operate IT Resources or handle Institutional Information are considered Suppliers. Also see UC BFB IS-3 Electronic Information Security, Section 15 for additional information about Supplier relationships. Synonym: Vendor |
|
|
The Traffic Light Protocol (TLP) was created to facilitate greater sharing of information. TLP is a set of designations used to ensure that sensitive information is shared with appropriate audiences. TLP uses four colors to define sharing boundaries to be applied by the recipient(s) indicating when and how sensitive information can be shared, and by facilitating more frequent and effective collaboration. |
|
|
In the context of information security, a Unit is a Campus academic or administrative entity led by a Campus appointed Unit Head with budgetary authority and resources of a level sufficient to accept and manage the organization’s information security risk. Units are the point of accountability and responsibility for Institutional Information and IT Resources. At UC Berkeley, the organizational level of a Unit in this context is Dean, VC, or AVC. Delegation is allowed if the delegation is explicit and includes budget and resources necessary to accept and manage information security risk at the delegated level, including covering an adverse information security event such as a data breach or system compromise. |
|
|
Unit Heads are the executives accountable and responsible for overseeing the execution of UC and Campus information security policies within the Unit. At UC Berkeley, the default level of a Unit Head in this context is Dean, VC, AVC, or other accountable executive in a senior role who is responsible for Unit performance and administration. Delegation is allowed if it is explicit, documented, and the delegate has the budget and resources necessary to manage information security risk, including an adverse information security event such as a data breach or system compromise. |
|
|
Known informally as "Security Lead". A term for the Workforce Member(s) appointed by the Unit Head and assigned responsibility for ensuring tactical execution of information security activities including, but not limited to: implementing security controls; reviewing and updating risk assessments; devising procedures for the proper handling, storing and disposing of electronic media within the Unit; and reviewing access rights. These activities are performed in consultation with the Unit Head. |
|
|
See "Individual Account" |
|
|
Individuals who access and use campus Institutional Information and IT Resources. |
|
|
See “Supplier” |
|
|
A person who supervises or manages other personnel or approves work or research on behalf of Campus. |
|
|
An employee, faculty, staff, volunteer, contractor, researcher, student worker, student supporting/performing research, medical center staff/personnel, clinician, student intern, student volunteer or person working for UC in any capacity or through any other augmentation to UC staffing levels. |