CWUR 7-70 Information Security

CWUR 7-70


CWUR 7-70-010 Information Security and Privacy Incident Management Procedure

(1) Procedure

This procedure describes the process used for assessing, responding to, and managing information security and privacy incidents (hereafter "incidents"). Incidents include, but are not limited to, unauthorized access, disclosure, modification, and destruction of institutional information and information systems.

(2) Incident Management

(A)   High Level Incident Management Process Flow

Figure 1 illustrates the high level incident management process flow and is described in the sections below.

 illustrates the high level incident management process flow and is described in the sections below.

(B)   Obligation to Report and Assist

Students, faculty, and staff shall immediately report potential incidents to their supervisor or Security Services department or designated office, as defined below. The incident reporting form is available on the Security Services website.

Third parties are contractually bound to limit the access, use, or disclosure of institutional information, information systems, computerized devices, or infrastructure technology, and shall promptly report potential incidents to the university employee who authorized their access, use, or disclosure. In addition, third parties are required to sign a non-disclosure agreement (NDA) and review university policies and procedures prior to commencement of any work.

Student, faculty, staff, and third parties shall provide full assistance with the investigation of any potential incident.

(C)   Analysis and Assessment

Based on the type of incident, the Chief Information Security Officer shall coordinate with the university designated offices identified in Table 1 in the analysis and assessment of a potential incident. Depending on the type of incident, the overall responsibility of the incident management process shall lie with the designated office.

Table 1. Designated Offices for Analysis and Assessment of Potential Incidents

 

Analysis and Assessment of Potential Incidents

Type of Incident

Designated Office

Scope

All incidents unrelated to student educational records, cardholder data, or protected health information

Security Services

All areas of the university

Student Educational Records

Office of the Registrar

All areas of the university

Cardholder Data

Financial Services

All areas of the university

Protected Health Information (PHI)

Medical Services

All areas of the university

Concurrent with the analysis and assessment, the designed office shall, where appropriate, work with data stewards and data custodians to obtain and preserve the necessary evidence associated with the incident.

If the designated office determines that an incident actually occurred, they shall conduct a risk assessment based on the sensitivity of the institutional information, impact to users, compliance requirements, criminal activity, and criticality of the information system to determine whether an incident should be referred to or shared with another designated office.

(D)  Incident Management

1. The Chief Information Security Officer shall, in collaboration with the designated office, assign an incident manager and assemble an incident management team that may include, but is not limited to, the following individuals or functional areas:

a. Chief Information Officer

b. Risk Management

c. Assistant Attorney General

d. Public Affairs

e. The appropriate data owner or data custodian

f. Executive heads of major university organizations

g. Chief Human Resources Officer

h. Academic and Student Life

i. University's subject matter experts on privacy laws or regulations related to the incident

2. The incident management team shall:

a. Review the initial analysis and assessment to determine the potential impact of the incident;

b. Assign additional resources, as needed, for further investigation and forensic analysis;

c. Develop and implement a plan to communicate within the University about the incident. The communication plan shall specify the recipients, content, and methods of communication; and

d. Determine whether notification of the incident to parties outside the university is necessary.

[02/21]

(E)   Notification

Notification of an incident shall be made as directed by the incident management team, and shall be carried out in accordance with applicable legal, regulatory, or contractual requirements. The incident manager, in collaboration with the designated office and the Public Affairs department, shall facilitate any notification to parties outside the university.

(F)   Reporting and Documentation

The incident management team shall prepare a written incident summary for each incident. The Chief Information Security Officer shall develop an incident log and perform a quarterly analysis of these summaries to identify trends.

(G)  Remediation

Remediation means efforts to address harm caused by the incident, if any, and efforts to address issues that led to the incident. Remediation may begin at any time, as appropriate, during the incident management process, provided evidence is preserved.

If an incident occurred and an incident management team is convened, the incident manager and designated office shall review and approve all proposed remediation actions. The designated office may also require the departmental unit(s) involved in the incident to develop a formal remediation plan.

If an incident did not occur and an incident management team was not convened, the Chief Information Security Officer will use the process described in Section (2)(C) to determine whether remediation is appropriate, and if so, the scope of any such effort.

[02/21]

(H)   Designated Office Responsibility

Each designated office shall develop, maintain, and follow an incident response plan that defines its procedures for analyzing and assessing a potential incident. The Chief Information Security Officer shall review and approve the incident response plans and the plans shall address, at minimum:

1. Documentation

2. Preserving evidence and chain of custody

3. Analysis and assessment

4. Referral and communication to designated official

5. Containment

6. Remediation

7. Reporting

(3) Procedure Maintenance

The Chief Information Security Officer shall review and recommend changes to this procedure statement at least annually or more frequently as needed to respond to changes within the institution and the regulatory environment.

 (4) Additional Information

For further information on this procedure or to report an incident, please contact the Security services department.

[5/04/2011; Responsibility: President’s Office; Authority: Cabinet/PAC; Reviewed/Endorsed by: Cabinet/PAC; Review/Effective Date: 6/4/2014; Approved by: James L. Gaudino, President]

(Back to the Top)

 

CWUR 7-70-050 Payment Card Procedures

(1)   Scope

In order to accept credit card payments, the University must prove and maintain compliance with the Payment Card Industry Data Security Standard (PCI DSS).  This procedure applies to all University entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers, as well as all other entities that store, process or transmit cardholder data and/or sensitive authentication data. For the intent of this document, a department or other functional unit that has been approved to process payment card transactions is known as a Merchant.

(2)   Procedures

In the course of doing business at the University it may be necessary for a department or institutional functional area to accept payment cards for payment. The University requires all departments that accept these payments to do so only in compliance with the PCI DSS, CWUP 2-70-040 Payment Card Policy and in accordance with the following procedures.

(A)   Card Acceptance Handling

The opening of a new merchant account for the purpose of accepting and processing payment cards has to be approved by the Director of Financial Services and is done on a case by case basis. No functional area may accept payment cards unless approved by the Director of Financial Services. Any fees associated with the acceptance of the payment card in that unit, will be charged to the unit.

1.     Interested departments should contact the Accounting department to begin the process of accepting payment cards. Steps include:

a)     completion of a Merchant Application;

b)     completion of required training; and

c)     reading and sign-off on the Payment Card Processing and Security Agreement, including ensuring ongoing compliance with all requirements of the applicable policies;

2.     Each Merchant is responsible to maintain internal controls that prevent payment card breaches and protect sensitive card holder information. In accepting payment cards, departments acknowledge they are responsible to hire qualified employees, train employees on proper procedures, and ensure that their employees adhere to all applicable University policies and procedures.

3.     Any Merchant accepting payment cards on behalf of the institution must designate an individual within the department who will have primary authority and responsibility within that department for payment card transactions and PCI DSS compliance requirements. This individual is referred to as the Merchant Department Responsible Person (MDRP). The Merchant should also specify a person of secondary responsibility should matters arise when the MDRP is unavailable.

4.     Specific details regarding processing and reconciliation will depend upon the method of payment card acceptance and type of merchant account. Detailed instructions will be provided when the merchant account is established and are also available by contacting the Accounting department.

5.     All service providers and third party vendors that provide payment card services must be PCI DSS compliant and be on the University approved payment card vendor list. The current approved vendors list is available on the Security Services web site. Merchants who contract with third-party service providers must maintain a list that documents their service providers and also:

·         ensure contracts include language that states that the service provider or third party vendor is PCI DSS complaint and will protect all cardholder data;

·         annually audit the PCI DSS compliance status of all service providers and third-party vendors with an understanding that a lapse in PCI DSS compliance shall result in the termination of the relationship; and

·         coordinate with the Information Services department for the installation of any software patches, upgrades, or fixes associated with the third-party vendor system(s).

(B)   Payment Card Data Security

The University recommends all Merchants develop business processes that specifically avoid storing of cardholder data in any form to reduce compliance requirements. Business processes and procedures that involve the handling and storing of cardholder data must be documented by Merchants and be available for periodic review by the Security Services department. Merchants must have in place the following components in their procedures and ensure that these components are maintained on an ongoing basis:

1.     Cardholder data collected are restricted only to those users who need the data to perform their jobs. Each Merchant must maintain a current list of employees with access and review the list monthly to ensure that the list reflects the most current access needed and granted.

2.     All equipment used to collect cardholder data is secured against unauthorized use or tampering in accordance with the PCI DSS.

3.     E-mail should never be used to transmit payment card or personal payment information, nor shall it be accepted as a method to supply such information. In the event that it does occur, disposal as outlined in section C.4 below is critical. If payment card data is received in an email then:

·   the email should be replied to immediately with the payment card number deleted stating that "Central Washington University does not accept payment card data via email as it is not a secure method of transmitting cardholder data"; and

·   securely destroyed as per section C.4 below.

4.     Fax machines used by a Merchant to receive payment card information shall be a standalone machine in a controlled environment with the appropriate physical security controls, as dictated by the PCI DSS. Sending of payment card data using a fax machine is not permitted.

5.     All University departments who are not Merchants must direct all individuals who pay a bill by credit or debit card to the Cashier’s Office or to its website. At no time will any department direct individuals to general-purpose kiosks for online credit card payments, unless the kiosk has been specifically identified as authorized to process credit cards.

(C)   Storage and Destruction

Cardholder data, whether collected on paper or electronically, must be protected against unauthorized access at all times. This shall include the following:

1.     Physical security controls are in place to prevent unauthorized individuals from gaining access to the buildings, rooms, or cabinets that store the equipment, documents or electronic files containing cardholder data.

2.     No database, electronic file, or other electronic repository of information will store the full contents of any track from the magnetic stripe, or the card-validation code.

3.     Portable electronic media devices shall never be used to store cardholder data. These devices include, but are not limited to, the following: laptops, compact disks, floppy disks, USB flash drives, personal digital assistants and portable external hard drives.

4.     Cardholder data should not be retained any longer than a documented business need; after which, it must be deleted or destroyed immediately following the required retention period. The maximum period of time the data may be retained is ninety (90) days. A regular schedule of deleting or destroying data should be established by the Merchant to ensure that no cardholder data is kept beyond the record retention requirements. All cardholder destruction must be in compliance with the PCI DSS.

5.     Purchasing Card data shall be protected in a similar manner and institute the above components, particularly as it relates to storage and disposal of cardholder data.

(D)   Reporting of a Security Incident

In the event of a breach or suspected breach of security, the Merchant must immediately contact the Security Services department in order to execute the CWUP 2-70-030 Incident Management policy

(3)   Procedure Maintenance

The Chief Information Security Officer and he Director of Financial Services shall review and recommend any change to this procedure statement at least annually or more frequently as needed to respond to changes in the regulatory environment and internal business practices.

[Responsibility: President’s Office; Authority: Cabinet/PAC; Reviewed/Endorsed by: Cabinet/PAC; Review/Effective Date: 06/04/2014; Approved by: James L. Gaudino, President]

(Back to the Top)

 

CWUR 7-70-080 Identity and Access Management Framework

Identity and access management (IAM) is a framework of business processes, policies and technologies that facilitates the management of electronic or digital identities.

(1) Scope

This procedure applies to all information systems and information resources owned or operated by or on behalf of the university. All university employees are responsible for adhering to this procedure and the associated policy, CWUP 2-70-080 Identity and Access Management Framework Policy.

(2) Procedure

IAM is a framework that consists of policies, procedures, and technologies to ensure users have the appropriate and necessary access to resources, services, and locations at the appropriate time. IAM is closely tied to governance, risk, and compliance.

(3) Framework

The IAM framework, from a simplified perspective, uses the model described below:

(A) CWU shall require a process for establishing levels of confidence in the digital identities used in systems, and a process to revoke them.

(B) Each entity should never correspond to more than oned digital identity, unless required for clearly defined and documented business or operational reasons (i.e. not convenience). Example of additional digital identities are given below.

Entities correspond to Identities consist of Attributes/Identifiers

(4) Examples

For example, the entity Senior VP, has one digital identity that allows logging into MyCWU. Another digital identity of the Senior VP that is connected to the connection card, allows access into certain buildings on campus (i.e. one entity with two identities).

Another example is the entity Technical Analyst, who has one digital identity that allows logging into MyCWU and another digital identity that allows privileged access to the network environments (i.e. A-account). The Technical Analyst also has a connection card with access to campus buildings (i.e. one entity with three digital identities).

A third example is a student employee who works for the Registrar and has access to student records. This student has a standard user account along with a department position account that grants her/him/them privileged access to the business systems. The student also has a connection card that allows access to her/his/their dormitory (i.e. one entity with three identities).

The intent is to keep the number of identities assigned to entities to an absolute minimum.

5) Provisioning

The provisioning process monitors access rights and privileges to ensure the security of university resources and user privacy. As a secondary responsibility, it ensures compliance and minimizes the vulnerability of systems to penetration and abuse. This process for assigning or revoking access rights should include:

(A) Requires authorization from the asset/data owner; separate approval for access rights from management may also be appropriate;

(B) Verifying that the level of access granted is appropriate and is consistent with other requirements such as segregation of duties;

(C) Ensuring that access rights are not activated before authorization procedures are completed;

(D) Maintaining a central record of access rights granted to information systems and services;

(E) Adapting access rights of users who have changed roles or jobs and immediately removing or blocking access rights of users who have left the organization;

(F) Periodically reviewing access rights with owners of the information systems or services.

(6) Control

Asset and data owners, as defined in the CWUP 2-70-010 Information Security and Privacy Roles and Responsibilities, should determine appropriate access control rules, access rights and restrictions for specific user roles towards their assets, with the amount of detail and the strictness of the controls consistent with the associated information security risks, or data classification as determined by the CWUP 2-70-020 Data Classification and Usage Policy.

(A) A formal, documented, and auditable process for authorization is required.

(B) Segregation of access control roles should be used (e.g. access request, access authorization, and access administration).

(C) Access is provided on the principle of least-privilege, need-to-know. You are only granted access to the information you need to perform your assigned tasks.

(D) Privileged access may require a separate digital identity for an entity, based on the associated information security risks and restrictions determined by the asset/data owner.

(E) Where appropriate, role-based access will be used to link access with business roles.

(F) Multi-factor authentication is required for all employees.

(7) Review of Access

(A) Asset/data owners or their designee should review users’ access rights at regular intervals.

(B) User access rights should be reviewed and re-allocated when moving from one role to another within the same organization;

(C) Authorizations for privileged access rights should be reviewed at more frequent intervals;

(D) Privilege allocations should be checked at regular intervals to ensure that unauthorized privileges have not been obtained;

(E) Changes to privileged accounts should be logged for periodic review.

(8) Responsibilities

For more information on roles and responsibilities, and definition of terms, refer to CWUP 2-70-010 Information Security and Privacy Roles and Responsibilities.

(9) Procedure Maintenance

The Chief Information Security Officer shall review and recommend any change to this procedure statement at least annually or more frequently as needed to respond to changes in the regulatory environment and internal business practices.

(10) Additional Information

For additional resources, further information on this policy statement, or for a definition of any term used in this policy document, please see the Security Services website at https://www.cwu.edu/about/offices/information-services/security-services/index.

[Responsibility: Operations Division; Authority: Cabinet/UPAC; Reviewed/Endorsed by: Cabinet/UPAC; Review/Effective Date: 04/14/2021; Approved by: James L. Gaudino, President]

(Back to the Top)

CWU News

Online Master’s of Education program now offers special education endorsement

May 15, 2024

by

Lenny Price brings Detroit perspective to CWU Jazz

May 15, 2024

by

More News