Information Security Management Program
Approved by President Ruben Arminaña and the Extended Cabinet on April 24, 2014.
Updates approved by Nate Johnson on May 20, 2015.
Updates approved by Douglass Berman on January 10, 2018.
Updates approved by the SSU Information Technology Advisory Committee on January 7, 2019.
Updates approved by the SSU Information Technology Advisory Committee on May 11th, 2020.
Updates approved by the SSU Information Technology Advisory Committee on March 7th, 2022.
1 Introduction
This Information Security Program describes how Sonoma State University will fulfill its obligations to protect those information assets for which Sonoma State University or its auxiliaries or other affiliated organizations hold ownership or responsibility.
2 Background
The CSU User Roles and Responsibilities Policy states that it is the collective responsibility of all users to ensure:
- Confidentiality of information that the CSU must protect from unauthorized access;
- Integrity and availability of information stored on or processed by CSU information systems;
- Compliance with applicable laws, regulations, and CSU/campus policies governing information security and privacy protection.
3 Program Goals
The goals of the Sonoma State University Information Security Program are to:
- Identify and manage information security risks and liabilities;
- Ensure compliance with all applicable laws, regulations, contracts, and California and CSU policies;
- Communicate responsibilities and minimum requirements.
4 Scope
The Sonoma State University Information Security Program applies to:
- All people, organizations, systems, networks, processes, media, and data for which Sonoma State University or its auxiliaries or other affiliated organizations hold ownership or responsibility; and
- All people, organizations, systems, networks, processes, media, and data to whom are given access to or custody of Information Assets for which Sonoma State University or its auxiliaries or other affiliated organizations hold ownership or responsibility.
5 Annual Review
The Information Security Officer, in collaboration with the Information Security Steering Committee, will annually review this program and will recommend needed revisions to the CIO for final review by the President and Information Technology Advisory Group (ITAG).
6 Should and Must Definition
Throughout this document, the words “must” and “should” have been carefully used to describe requirements. While both terms denote a requirement that needs to be followed, the process for making exceptions differs.
Exceptions to a "should" requirement must be approved by an appropriate administrator and by all affected data owners. The Information Security Office must also be notified of the exception.
Exceptions to a "must" requirement must be approved by an appropriate administrator, by all affected data owners, and by the Information Security Office.
In either case, exceptions are only to be granted if either:
- The risk addressed by the requirement does not exist in a given context; or
- The risk addressed by the requirement is being addressed by other controls that would compensate for not fulfilling the requirement.
7 Roles and Responsibilities Standard
Implements ISO Domain 6: Organization of Information Security Policy and the CSU Roles and Responsibilities Policy.
7.1 Data Owner or Data Authority
The roles of Data Owner and Data Authority have the same responsibilities and the terms are used interchangeably in the SSU Information Security Management Program. A Data Owner or Data Authority is responsible for decisions related to data access, use, storage, and protection of a particular type or collection of data. The data owner or data authority is an individual, not a group, department, or committee. This individual may delegate tasks. For assistance in identifying data owners or data authorities in ambiguous situations, see the ISO Domain 8: Asset Management Standard.
It is the duty of the Data Owner or Data Authority to:
- inventory and classify data according to the ISO Domain 8: Asset Management Policy;
- comply with the ISO Domain 9: Access Control Policy and the SSU Access Control Standard in authorizing, tracking, and documenting:
- end users of data,
- uses of data, and
- stewards of data (those who store and protect the data);
- work with the Information Security Office to identify an acceptable level of risk for the data;
- work with the Information Security Office to specify and document data controls and convey them to Data Users and Data Stewards. These controls must comply with the ISO Domain 8: Asset Management Standard, the SSU Physical Security standard, and SSU Access Control standard. These controls may include, but are not limited to, passwords, access control, encryption, physical locks, and backups;
- annually:
- confirm with Data Stewards that controls are in place, and
- review access lists;
- work with the Information Security Office to approve, justify, and document exceptions to security controls;
- perform other duties and fulfill other requirements described in the CSU Information Security Roles and Responsibilities Standard and any other CSU and SSU policies and standards when and as necessary.
7.2 Data Steward
Data Stewards are appointed and authorized by the Data Owner to store and protect the data. Examples include: Computer System Administrators, Database Administrators, and Managers of physical storage locations or facilities.
It is the duty of a Data Steward to:
- perform regular backups of the data;
- restore data from backup media;
- implement and follow all controls specified by the Data Owner and the Information Security Office;
- notify the Data Owner and the Information Security Office of any vulnerabilities impacting the security of the data, and of any actual or attempted violations of security policies, standards, practices, and procedures;
- perform other duties and fulfill other requirements described in the CSU Information Security Roles and Responsibilities Standard and any other CSU and SSU policies and standards when and as necessary.
7.3 Data User
Data Users are individuals who need and use University data as part of their assigned duties or in fulfillment of assigned roles or functions within the University community. Individuals who are given access to sensitive data have a position of special trust and as such are responsible for protecting the security and integrity of that data.
It is the duty of a Data User to:
- follow all CSU and SSU security policies and standards;
- use data only in authorized manners;
- follow all controls specified by the Data Owner and the Information Security Office;
- not subject any university information asset to a level of risk beyond that approved by the Data Owner;
- perform other duties and fulfill other requirements described in the CSU Information Security Roles and Responsibilities Standard and any other CSU and SSU policies and standards when and as necessary.
7.4 Information Security Officer
It is the duty of the Information Security Officer to:
- coordinate the campus information security program on behalf of the President;
- advise the President and his/her cabinet on all information security matters;
- work closely with campus administrators and executive officers on information security matters;
- oversee campus information security risk assessment activities;
- inform the President (or President designee) of significant information security risks as they are identified;
- oversee the campus information security incident response program in coordination with appropriate campus personnel;
- oversee the campus information security awareness and training program;
- provide input to the campus regarding information security risk mitigation activities and inputs regarding information security risks of proposed projects;
- respond to information security related requests during an audit;
- serve as the campus representative on the CSU Information Security Advisory Committee;
- avoid conflicts of interest by not having direct responsibility for information processing or technology operations for campus programs that employ protected information;
- provide input to campus Business Continuity and Disaster Recovery policies and procedures;
- perform other duties and fulfill other requirements described in the CSU Information Security Roles and Responsibilities Standard and any other CSU and SSU policies and standards when and as necessary.
8 Risk Management Standard
Implements ISO Domain 6: Organization of Information Security.
8.1 Risk Assessments
The Information Security Office will conduct on-going campus-wide information security risk assessments with the intent to assess each of the identified areas at least every two years.
8.2 Response to Identified Risk
Once a risk has been identified, the CIO, with assistance from the Information Security Office and the IT Project Management Office, will create a proposal to mitigate (including timeline and prioritization), transfer, or accept the identified risk. The Information Technology Advisory Group (ITAG) will review this proposal for approval on behalf of the university.
The response must reduce the risk to acceptable levels (risk mitigation), share or shift the risk to another party (risk transference), or assume the identified risk (risk acceptance). An information security risk can only be accepted by the President of the University and/or his/her designee.
8.3 Reporting
In compliance with the Incident Reporting Policy(ISO Domain 16: Incident Management Standard)
, the Information Security Officer will share appropriate information about campus wide information security risk with the CSU Chief Information Security Officer.
9 Personnel Security Standard
Implements Personnel Information Security Activities (ISO Domain 7: Human Resource Security Policy).
9.1 Revoking Access to Protected Data
When an employee no longer needs access to protected data due to a change of duties within a department, the employee’s Appropriate Administrator must notify the Data Owners of the protected data. The Data Owners must review the employee’s access and revoke any access not otherwise authorized.
When an employee no longer needs access to protected data due to an inter-department change of position, the employee’s former Appropriate Administrator, Human Resources, or Faculty Affairs, as appropriate, must notify the Data Owners of the protected data. Human Resources or Faculty Affairs, as appropriate, must send an email to the employee’s former Appropriate Administrator as a reminder of this requirement. The Data Owners must review the employee’s access and revoke any access not otherwise authorized.
When an employee ends their employment at Sonoma State University, the employee must clear campus as per the Sonoma State campus clearance process. Unless otherwise authorized, access to all campus protected data must be revoked. Human Resources or Faculty Affairs, as appropriate, must send an email to the employee’s former Appropriate Administrator as a reminder of this requirement.
9.2 Background Checks
Criminal Background Checks must be performed at the time of hire on any employee, staff, faculty, student assistant, consultant, volunteer, or other person performing work for the university, who will handle Level 1 Protected Data. These employees must be identified by their Appropriate Administrator when filling out the personnel requisition form.
9.3 Confidentiality Agreements
All employees, staff, faculty, student assistants, consultants, volunteers, and other persons performing work for the university must, at time of hire, sign a confidentiality agreement.
9.4 Disposition of Information Assets Upon Ending Employment
When an employee ends their employment at Sonoma State University, electronic and paper files must be promptly reviewed by an appropriate manager to determine who will become the data steward of such files and identify appropriate methods to be used for handling the files. If the separating employee is holding resources subject to a litigation hold and/or criminal investigation, the relevant information must be preserved until the litigation hold has been revoked, at which point the resource is subject to the normal record retention schedule.
Upon ending employment, if a former employee wishes it to obtain a copy of any personal electronic information stored on campus information assets, the former manager and Human Resources or Faculty Affairs, as appropriate, must either provide the personal electronic information to the former employee or allow the former employee to obtain the personal electronic information in a manner that preserves the integrity of all campus information assets.
10 Information Security Awareness Training Standard
Implements Information Security Training and Awareness Activities (ISO Domain 7: Human Resource Security Policy).
Because the following community members may come into contact with sensitive data in the course of their work, Information Security Awareness Training will be assigned annually to all SSU staff, faculty, administrators, currently working annuitants, consultants, auxiliary employees, student assistants, and volunteers with access to Sonoma State information technology resources.
The training must be completed within two months of its assignment, and will automatically be reassigned one year after completion.
11 Vulnerability Management Standard
Implements ISO Domain 12: Operations Security Policy.
11.1 Discovering Vulnerabilities
Vulnerabilities may be discovered in multiple ways, including but not limited to the following:
- Network-based vulnerability scans authorized by the Information Security Office;
- Penetration testing authorized by the Information Security Office;
- Security reviews performed by the Information Security Office;
- Vendor announcements;
- Published vulnerability information;
- Local discoveries.
11.2 Remediating Vulnerabilities
Remotely exploitable vulnerabilities that allow systems to be compromised and are being actively deployed against the University must be remediated as soon as a fix is available.
Other remotely exploitable vulnerabilities that allow systems to be compromised must be remediated no more than one week after a fix becomes available.
Other vulnerabilities must be remediated within 90 days.
11.3 Accepting Vulnerabilities
A reported vulnerability may be accepted only if:
- the reported vulnerability does not represent an actual vulnerability; or
- the risk associated with the vulnerability is mitigated by a compensating control.
12 Monitoring Standard
Implements Information Asset Monitoring (ISO Domain 12: Operations Security Policy).
Campus information systems and assets must implement logging and monitoring, including appropriate limitations on the collection, access, and use of all logs and monitoring data, and must protect, retain, and dispose of all logs and monitoring data, as described in the CSU Information Technology Security Policy, the Logging Elements (ISO Domain 12: Operations Security Standard), and CSU Executive Order 1031 - Systemwide Records/Information Retention and Disposition Schedules Implementation.
13 Configuration Management Standard
Implements Configuration Management (ISO Domain 12: Operations Security Policy).
13.1 Default Configuration
All workstations, including laptops, upon purchase or transfer between departments should be set up with a standard configuration by IT that meets or exceeds the minimum workstation configuration standards issued by the CSU system. Departments wishing to configure and administer their machines differently must provide the CIO or CIO’s designee with an authorization signed by an appropriate administrator. Additionally, this alternate configuration must still comply with all SSU and CSU security standards and policies including the SSU Vulnerability Management Standard and the SSU Configuration Management Standard.
13.2 Anti-virus and Anti-malware
All workstations of a type commonly affected by malicious software, including laptops, must have appropriate anti-virus and anti-malware software installed. The software and its malware definitions must be updated regularly. The software must be configured to run a full scan weekly and must have “on access” scanning enabled to prevent malware from running. This software should be centrally managed by Information Technology.
13.3 Mobile Device Management
Mobile devices (with the exception of laptop computers) must not contain Level 1 Protected Data. These devices must only access services that are accessible from the public Internet.
13.4 Laptops
Those wishing to use a laptop for any purpose involving access to, or storage of, Level 1 Protected Data must identify, and receive approval from, the Data Owner. Additionally, the device must have IT supported whole disk encryption. Laptops are also subject to all workstation configuration and patching requirements.
13.5 Remote Computing
Level 1 Protected Data must never be stored on or accessed using personally owned devices. All Level 1 Protected Data transported off campus for remote computing usage, or accessed from off campus, must only be stored on or accessed using campus issued computers and storage devices. These computers and devices must be configured with full disk encryption and must comply with the SSU Configuration Management Standard. As with all other storage, transportation, and use of Level 1 Protected Data, all remote storage, transportation, and use of Level 1 Protected Data must be approved by the appropriate Data Owner.
All devices, including personal devices, used to store or access Level 2 Protected Data must comply with the SSU Configuration Management Standard.
13.6 Operating System and Software Updates
13.6.1 Workstations
Workstations that are centrally managed by IT will automatically receive operating system and software updates at least quarterly. Those workstations that are not centrally managed should be running a currently supported operating system and should receive operating system and software updates at least quarterly.
13.6.2 Servers
Servers should be running a currently supported operating system and should have their operating system and software updated at least quarterly.
13.6.3 All other devices
All other devices connected to the Sonoma State network should be currently supported by the vendor. Operating system, software, and/or firmware updates should be applied within 90 days of release.
13.6.4 Exceptions
Operating system and software updates may be postponed if an update will cause issues such as incompatibility with other software. Exceptions must be documented and renewed at least annually.
14 Change Control Standard
Implements Change Control (ISO Domain 12: Operations Security Policy).
All configuration changes to information assets or systems that process, store, receive, transmit, or use CSU protected Level 1 data must be tracked and documented. The documentation must include:
● the nature of the change;
● the expected and potential impact of the changes, including security implications;
● whether or not the change can be undone if needed, and if so, how;
● the identity of the person making the change;
● the identity of the person reviewing and approving the change;
● the time that the change was made; and.
● the results of testing the change.
Changes should be scheduled so as to keep the impact upon users of any affected services to an acceptable level.
Departments responsible for information assets or systems that process, store, receive, transmit, or use CSU protected Level 1 data must:
- establish criteria, based on risk, that specify when stakeholders must be notified of intended changes and given an opportunity to offer input or raise concerns;
- establish criteria, based on risk, that specify when changes must be formally approved by an appropriate administrator; and
- formally identify individuals who are authorized to make emergency changes that, due to urgency or criticality, need to occur outside of the department’s formal change management process. Such emergency changes must be appropriately documented and promptly submitted, after the change, to the department’s normal change management process.
Appropriate stakeholders must be notified about completed changes and system documentation must be updated to reflect these changes.
15 Access Control Standard
Implements ISO Domain 9: Access Control Policy.
15.1 Authorization
Access to Protected Data must be denied until specifically authorized. Authorization to access Level 1 Protected Data must be granted on a per user basis by the Data Owner of the data to be used using the SSU Request for Access to Protected Data form. These authorizations must follow the principles of need to know, operational need, least privilege, and separation of duties. Data Owners must track any access modifications.
15.1.1 Third Parties
Third parties wishing to access Level 1 Protected data must also receive authorization from affected Data Owners, and must follow all applicable CSU and SSU policies, standards, laws, and contracts.
15.1.2 Review
Data Owners must review and renew all access authorizations on a specified date annually. This must be logged on the request form used for the original authorization. This review must include an evaluation of what level of access individuals need to perform their current job function. Access unrelated to legitimate business activities must be revoked.
15.2 Authentication
15.2.1 Unique Credentials
Unique credentials should be used for accessing all campus information systems.
Exceptions allowing the use of shared credentials must be approved by the requesting departments’ manager and by all affected data owners. The manager and all affected data owners must be informed of the associated risks. The department administering the system being accessed with shared credentials must track all shared credentials in use, must require shared credentials to be reauthorized at least annually, and must deactivate any shared credentials that are not reauthorized.
15.2.2 Keeping Personal Credentials Private
Personal Sonoma State credentials must remain private at all times. The credentials to an account can be used in malicious ways that could cause harm to an individual or the university.
Users should not under any circumstances share their personal password with anyone, whether affiliated with the university or not.
15.2.3 Issuing Credentials
When passwords are issued they must be one-time Passwords/Keys. One-time passwords (e.g., passwords assigned during account creation, password resets, or as a second factor for authentication) must be set to a unique value per user and changed immediately after first use.
15.2.4 Central Authentication
All production SSU web applications used by campus community members must perform centralized authentication based on Seawolf IDs and passwords.
Non-IT run services, including all outsourced services, must use an authentication technology (such as CAS or Shibboleth) that does not expose the password to the web application server.
15.2.5 SSL Login Requirement
When authenticating to any service hosted on Sonoma State’s network, or any service provided by a third party on behalf of Sonoma State, the communication of credentials must use secure settings and strong encryption mechanisms such as SSL or TLS. For example, webpages into which one types a password must use HTTPS instead of HTTP.
15.3 Passwords
15.3.1 Requirements
Password minimum length, complexity requirements, expiration, and lockout after failed logins must meet NIST level 1 “resistance to guessing authentication secret” as per the ISO Domain 12: Access Control Standard
To contain the damage resulting from a service compromise, and to minimize the potential harm to both SSU and individual users, SSU passwords must not be reused with non-SSU services such as personal email, social media, personal banking, and Internet message boards.
15.3.2 Storage
Passwords stored in any non-electronic form must be protected with appropriate controls, including but not limited to being locked up or carried on one’s person at all times.
Any passwords stored electronically (except for service accounts) must be stored using IT-supported encrypted password management software.
15.4 Public and Shared Resources
Level 1 or 2 Protected assets must never be made public. Campus personnel are encouraged to use discretion and good judgment when deciding what other information to make public, and must comply with all applicable SSU and CSU policies and standards, all applicable laws, and all applicable contractual requirements, when doing so.
16 Data Inventory Procedure
Implements ISO Domain 8: Asset Management Policy.
Annually, SSU will conduct an inventory of Level 1 data (as defined by the CSU Data Classification Standard). This inventory will be completed by distributing a Level 1 Data Inventory Survey to all identified data owners and Admin II managers or higher.
This survey is to be completed and returned to the Information Security Office.
The Information Security Office will be available to help users complete the Data Inventory survey by appointment.
17 Cloud Procurement Standard
Implements CSU Cloud Storage and Services (ISO Domain 8: Asset Management Standard)
The purpose of this standard is to ensure that CSU data is appropriately stored or shared using public cloud computing and/or file sharing services.
Per the CSU Standard, cloud computing and file sharing is defined as the utilization of an information technology service of any type that is not provided by servers which are owned/leased by the CSU or auxiliaries including, but not limited to, social networking applications, file storage, and content hosting.
Examples of cloud services include web-based email, web-based file storage, and other web-based services that are hosted by a vendor rather than being run locally on campus.
Only authorized third-party services or hosted services may be used to access, exchange, store, process or analyze campus data, or to provide the campus with critical operational technologies. Only Procurement is authorized to contract with third-party or hosted service providers.
Even if a service is free of charge, including trial periods, only Procurement is authorized to enter into a contract for its use. This includes any website requiring a "Click to Accept" action to access the services.
The department purchasing a cloud service must provide IT with:
- the Technology Purchase Review request; and
- a VPAT supplied by the vendor. (If you cannot find a VPAT, IT will search for one.)
The Technology Purchase Review form allows for a technical feasibility check in addition to supportability. The department must also provide a clear description of the application or service within the Technology Purchase Review form.
A VPAT must be filled out and submitted to IT for a review. The initial IT review typically takes no more than five business days. Once reviewed, IT will then return the forms either approved or denied. If approved, the department will need to fill out an EREQ for Purchasing. If denied, IT will work with the department and Purchasing on alternatives.
The department purchasing a cloud service must fill out and provide Purchasing with:
- Department Cloud Usage Checklist (Seawolf ID required); and
- the EREQ (E-Requisition, including the approved Technology Purchase Review Request and the VPAT)
The Department Cloud Usage Checklist elaborates on what kind of data is being stored and how said data will be accessed. EREQ or E-Requisition is required when purchasing any cloud service.
The vendor must provide Purchasing with at least one of the Security Practices Checklists referenced in 5.3 of the Cloud Storage and Services (ISO Domain 8: Asset Management Standard).
During Purchasing's review of the contract, if one or more of the following are true, then the ISO will evaluate the risk of the third-party service or hosted service.
- if the third-party/hosted service will be storing level 1 or 2 data,
- if the vendor wishes to deviate substantially from the IT Supplemental Provisions,
- if the service is unable to use Sonoma State's Central Authentication, or
- if there are any security concerns that are identified during the review.
At any point in the evaluation of a service, the ISO holds the right to evaluate the risk of the third-party service or hosted service.
18 Information Asset Management
Implements CSU Cloud Storage and Services (ISO Domain 8: Asset Management Standard)
The purpose of this standard is to ensure that SSU data is appropriately stored or transmitted.
18.1 Storage and Transmission of Sensitive Data
The following table provides information about appropriate methods for storing and transmitting different levels of data
Application / Hardware | Level 1 | Level 2 | Level 3 | Any data encrypted using strong encryption (Level 1, 2 or 3) |
---|---|---|---|---|
Adobe Sign | Yes | Yes | Yes | Yes |
Encrypted flash drive (Apricorn, Corsair) | Yes | Yes | Yes | Yes |
Hard drives with full disk encryption | Yes | Yes | Yes | Yes |
OnBase | Yes | Yes | Yes | Yes |
Qualtrics | Yes | Yes | Yes | N/A |
MoveIT Transfer | Yes | Yes | Yes | Yes |
Yuja | Yes | Yes | Yes | N/A |
Zoom | Yes | Yes | Yes | N/A |
SSU-Alpha file server | Yes | Yes | Yes | Yes |
SSU-Beta file server | No | Yes | Yes | Yes |
SSU-Google Drive | No | Yes | Yes | Yes |
SSU-Google Forms | No | Yes | Yes | No |
Drupal Forms | No | Yes | Yes | No |
Unencrypted flash drive | No | Yes | Yes | Yes |
Unencrypted external hard drive | No | Yes | Yes | Yes |
SSU-Email | No | Yes | Yes | Yes |
Some examples of strong encryption include:
- PDFs encrypted with compatibility set to "Acrobat 7.0 and later (PDF 1.6)" or "Acrobat X And later (PDF 1.7)";
- Zip files encrypted using AES-256 encryption and NOT standard zip encryption; (These can be created using 7zip and WinZip.)
- Password protected files created with Microsoft Office 2007 or newer; and
- Email encrypted with S/MIME.
Files must be encrypted using a strong password that is not stored or transmitted with the encrypted files, and not transmitted using the same medium. For example, it is acceptable to email an encrypted PDF and communicate the password over the phone.
Please contact the IT Help Desk at it.helpdesk@sonoma.edu or (707)664-HELP for assistance with securely storing sensitive information.
18.2 Data Sharing Guidance for Information Security Threats and Vulnerabilities
SSU community members who receive information about information security threats and vulnerabilities that are labeled with a Cybersecurity & Infrastructure Security Agency (CISA) Traffic Light Protocol (TLP) designation are required to follow the TLP sharing guidance for that designation.
18.3 Media disposal and reuse
When disposing of paper containing Level 1 or Level 2 data, it must be shredded with a crosscut shredder.
When disposing of electronic storage media, it must be securely erased or destroyed using IT approved procedures.
All electronic storage media must be securely erased using IT approved procedures before being redeployed to a new user .
19 Information Security Incident Response Standard
Implements ISO Domain 16: Incident Management Standard.
19.1 Information Security Incident Response Team Membership
The core Information Security Incident Response Team (ISIRT) consists of representatives from:
- Seawolf Services;
- Human Resources;
- Information Security Office;
- Information Technology Infrastructure;
- Information Technology Workstation Support;
- Networking;
- Marketing & Communications;
- Police;
- Risk Management.
19.2 Types of Incidents
The Information Security Incident Response Team (ISIRT) will investigate and respond to Information Security incidents involving malware, fraud, harassment, inappropriate use, unauthorized data access, unauthorized physical access, unauthorized system access, unauthorized system use, lost or stolen equipment, other violations of applicable Information Security laws, policies, standards, procedures and contracts, and other violations of the confidentiality, integrity, or availability of information systems or assets for which Sonoma State University holds responsibility.
19.3 Incident Response Procedure
19.3.1 Detection of Incidents
Some possible ways of detecting events include:
- Unusual network activity;
- Unusual server log entries;
- A denial of service (workstation, network, or service);
- The University is contacted by other organizations;
- The University is contacted by Police Services;
- The University is contacted by an end-user noticing strange behavior; or
- Alerts from security monitoring systems.
Detection can often occur at:
- A network perimeter (network firewall or network Intrusion Detection System);
- A host perimeter (host based firewall);
- On the system-level (on the host itself);
19.3.2 Reporting
Persons who suspect a security incident should contact the SSU IT Help Desk in one of the following ways:
- Send email to helpdesk@sonoma.edu; or
- Call 707-664-HELP (contact by email if there is no answer); or
- Visit the SSU IT Help Desk at the main entrance to IT, on the first floor south wing of the Schulz Information Center.
Please inform the IT Help Desk of the nature of data stored and accessed on any system suspected of being compromised, to the extent that this can be done without using or accessing the system itself.
Callers should state, in particular, if CSU protected level 1 or 2 data violations are suspected such as Social Security Numbers, medical information, grades, or other CSU protected level 1 or 2 data as defined in The Data Classification Levels (Asset Management ISO Domain 8 Standard).
19.3.3 Loss or Theft of Equipment or Media
When a computing device has been lost or stolen, an equipment loss report must be filed with Property Management.
When a computing device has been stolen, the theft must also be immediately reported to The Sonoma State Police Department.
When a computing device or a piece of storage media containing protected level 1 data has been lost or stolen, it must also be immediately reported to the Information Security Office. The Information Security Office will then follow the SSU Information Security Incident Response Procedure. Storage media includes, but is not limited to, storage devices, USB drives, paper, and any other storage media.
19.3.4 Notification of CSU Chief Information Security Officer
If a reasonable suspicion exists that Level 1 data has been breached, the Information Security Officer, in consultation with the Chief Information Officer (CIO), must notify the CSU Chief Information Security Officer and the SSU Emergency Management Office as soon as possible of the potential incident.
19.3.5 Preservation of Evidence
If a system is suspected of having been compromised, to avoid inadvertently destroying valuable evidence needed to protect other systems and to prove that protected information was not accessed, users and IT support staff must not:
- install or run any additional services, patches, upgrades, or other fixes;
- run anti-malware scans or backup software; or
- use the machine further for any purpose.
The Information Security Office has forensic software to preserve as much of the evidence as possible from a compromised computer.
19.3.6 Containment of Damage
If a compromised system is believed to be exfiltrating data or attacking other systems, the system must be immediately disconnected from the network.
If the presence of malicious software has been detected then the machine in question must immediately cease to be used and must be disconnected from the network. The Information Technology Help Desk must be notified. The machine must be examined for sensitive data and fully cleaned before use can continue.
19.3.7 Incident Investigation
The Information Security Office will, with assistance, as needed, from members of the Information Security Incident Response Team (ISIRT) and other campus community members, investigate and document the incident, and attempt to determine what information assets may have been involved, what damage may have been caused, what data may have been breached, and the identity and actions of the perpetrators. When a crime is known or suspected to have been committed, or when there is a possibility that notifications under the California Civil Code will be made, the Information Security Office will file a police report with the Sonoma State Police Department.
All campus community members must work with the Information Security Office, the Data Owner, the Data Steward, and/or other authorized individuals during the investigation and mitigation of information security incidents and breaches.
19.3.8 Recovery and Remediation
The Information Security Office will work with the affected parties to create and implement a plan to recover from the incident and remediate damage caused by the incident.
Where appropriate, violations of laws, policies, standards, procedures, contracts, or codes of conduct will be referred to other departments such as the Office of Student Conduct, Employee Relations and Compliance, Residential Life, or Faculty Affairs for further investigation or action.
19.3.9 Determining Notification Requirements
If confidential information is involved and if there is reasonable belief that it was compromised, the following actions are taken:
The Information Security Officer and/or the CIO will make a recommendation to the President about whether to make a formal breach notification. The Information Security Officer and/or the CIO will be advised by Senior Management as available and appropriate, including:
- Vice President of Administration and Finance;
- Vice President of University Affairs;
- Strategic Communications representative;
- Web Services Director; and
- Director of Risk Management.
The President or designee will decide whether the University is to make a formal breach notification; If a breach notification is to be made:
- The President or designee will decide whether to notify individually, through the media, or both, and assigns tasks;
- A draft copy of the notification must be sent to the CSU Chief Information Security Officer for review;
- The notification will be sent to the user and/or published, as decided by the President.
Additional notifications are made according to ISO Domain 16: Incident Management Standard and other contractual and legal requirements. These include but are not limited to:
- If a breach of level 1 data has occurred, the President notifies the Chancellor, the CIO notifies the Assistant Vice Chancellor for Information Technology Services, and the campus ISO notifies the CSU Chief Information Security Officer using the Chancellor’s Office Security Incident Response Form;
- If a breach of PCI data has occurred, the affected payment brands are notified and the appropriate procedures are followed from the payment brand incident response procedures; and
- Breaches involving data exchanged with other entities are reported to those other entities as appropriate.
Follow up meetings are held to monitor the status of the notification effort.
19.3.10 Handling Inquiries
In the event that notification of the incident is given to members of the public or the campus community, the Information Security Incident Response Team (ISIRT) will work with Strategic Communications to determine what methods will be used for handling inquiries about the incident. Possible methods include but are not limited to the creation of a website dedicated to the incident and the temporary use of the campus information/emergency phone line message.
19.3.11 Follow-up
The Information Security Office will lead a follow-up conversation to identify and apply lessons learned, and to develop and implement corrective actions directed at preventing or mitigating the risk of similar occurrences.
19.3.12 Closing the Incident
When all outstanding action items have been completed, the Information Security Office will close the incident and notify the President and the Information Security Incident Response Team (ISIRT).
20 Physical Security Standard
Implements ISO Domain 11: Physical and Environmental Security Policy.
20.1 Purpose
All areas containing Level 1 Protected data must be physically protected as per the ISO Domain 11: Physical and Environmental Security Policy.
20.2 Identifying Security Zones
Shared Access Areas and Campus Limited Access Areas will be identified based on responses to the annual Data Inventory Survey and criteria set by the ISO Domain 11: Physical and Environmental Security Standard.
20.3 Appropriate Controls
20.3.1 Viewing Controls
The display screens for all campus information systems that have access to protected data must be positioned such that data cannot be readily viewed by unauthorized persons (e.g., through a window, by persons walking in a hallway, or by persons waiting in reception or public areas). If it is not possible to move a display screen to meet the above requirement, a screen filter must be used.
20.3.2 Shared Access Areas
- Doors controlling access to the area should be locked when the area is unattended;
- Entrance to the area should be monitored and controlled by a trusted individual when the doors are unlocked;
- Guests should always be monitored by persons who can prevent unauthorized access to the protected information assets or critical systems in the area;
- Assets that contain or access Level 1 Protected data and can be removed by a single individual, including but not limited to computers or small lock boxes, must be physically locked down, must be directly supervised at all times, or must utilize full disk encryption. These include, but are not limited to, computers, storage devices, storage media, USB drives, paper, and small lock boxes;
- Cabinets containing Level 1 Protected data must be kept locked, may only be unlocked while the contents are being accessed, and must be relocked immediately afterwards;
- Workstations that store, process, transmit, or access Level 1 Protected data must be locked with a password when unattended. This password must comply with the password requirements in the SSU Access Control standard.
20.3.3 Campus Limited Access Areas
- Doors controlling access to the area must always be locked;
- Guests must always be logged and monitored by persons who can prevent unauthorized access to the protected information assets or critical systems in the area;
- Cabinets containing Level 1 Protected data must be locked when unattended;
- Workstations that store, process, transmit, or access Level 1 Protected data must be locked with a password when unattended. This password must comply with the password requirements in the SSU Access Control standard;
- Authorization to access the area must be explicitly granted and documented;
- Where supported by access controls (for example, card locks), access to the area must log access times and the identity of individuals accessing the area.
21 Compliance Standard
Implements ISO Domain 18: Compliance Policy.
21.1 PCI DSS (Payment Card Industry Data Security Standard)
In accordance with CSU Debit/Credit Card Payment Policy, all people, processes, and systems within the scope of the Payment Card Industry Data Security Standard (PCI DSS) must comply with the PCI DSS in the manner(s) specified by the SSU PCI Data Authority.
21.2 Legal Compliance
All University business must be conducted in compliance with all applicable laws, including but not limited to FERPA (Family Educational Rights and Privacy Act), GLBA (Gramm-Leach-Bliley Act), and HIPAA (Health Insurance Portability and Accountability Act).
21.3 Identity Theft Prevention and Red Flags (FTC Red Flags Rule)
21.3.1 Definition and Purpose
A red flag is an event or observation that indicates a heightened probability of identity theft.
Identity theft is strongly related to credit fraud, and Sonoma State University extends credit to students in the form of Student Loans and Payment Plans.
This standard describes examples of red flags to notice, should they appear in the course of daily business, and direction in responding to red flags.
21.3.2 Possible Red Flags
Red flag events include notification of the University by law enforcement, a credit reporting agency, a victim of identity theft, or another party, that an identity theft has occurred or is suspected of having occurred.
Red flag observations can include anything suspicious about a customer, documents provided, or information provided.
Customer red flags include inconsistencies between the customer's appearance or voice and the photograph or physical description in University records or on the presented identification.
Document red flags include any evidence that a piece of identification, a form, or any other document, has been forged, altered, or destroyed and reassembled.
Information red flags include:
- Information, including signatures, conflicting with other information provided by the customer, on file with the University, or available from external sources;
- Information expected to be unique to an individual, such as a Social Security number, being shared by multiple customers;
- Social Security Numbers that have not been issued or that appear in the Social Security Administration’s Death Master File;
- Contact information known by the University to have been previously used for fraudulent purposes.
21.3.3 Detection of Red Flags
Some red flags are detected automatically, such as certain kinds of invalid information, some red flags are detected through manual observation, and some are only detected when suspicious circumstances have prompted investigation. Most red flags are most likely to be discovered during the process of authenticating a student.
21.3.4 Response to Red Flags
The detection of a Red Flag by an employee shall be reported to their appropriate administrator and to the IT Helpdesk as per the Sonoma State Information Security Incident Response Standard.
Based on the circumstances and the type of red flag, the Appropriate Administrator and the Information Security Incident Response Team, together with the employee will determine the appropriate response.
Appropriate responses may include:
- Enhanced authentication measures;
- Contacting the individual;
- Not lending money;
- Not attempting to collect on a debt or not selling a debt to a debt collector;
- Notifying law enforcement; or
- Determining that no response is warranted under the particular circumstances.
21.3.5 Service Providers
The University remains responsible for compliance with the Red Flags Rule even if it outsources operations to a third party service provider. The written agreement between the University and the third party service provider shall require the third party to have reasonable policies and procedures designed to detect relevant Red Flags that may arise in the performance of the service provider’s activities. The written agreement must also indicate whether the service provider is responsible for notifying only the University of the detection of a Red Flag or if the service provider is responsible for implementing appropriate steps to prevent or mitigate identify theft.
21.3.6 Training
All employees who process any information related to a covered account shall receive training to understand their responsibilities associated with the Identity Theft Protection Standard.
22 Enforcement and Investigation Standard
Implements CSU Enforcement Policy.
Investigations involving employees and students suspected of violating the CSU or SSU Information Security policy must be conducted in compliance with all applicable laws, regulations, collective bargaining agreements, and CSU and SSU policies.
SSU reserves the right to temporarily or permanently suspend, block, or restrict access to information assets, independent of such procedures, when it reasonably appears necessary to do so in order to protect the confidentiality, integrity, availability, or functionality of SSU resources or to protect SSU from liability.
23 Credits and Acknowledgements
Written and maintained in consultation with:
- Accounting
- Compliance
- Computer Science
- Faculty Affairs
- Financial Aid
- Human Resources
- Information Technology
- Institutional Research
- Procurement
- Risk Management
- School of Education
- Seawolf Services
- Strategic Communications
- Student Affairs
- University Advancement
- University Police
Portions derived, with permission, from the San Diego State University Information Security Plan.
Portions derived, with permission, from the Sacramento State Information Security Policies and Standards.
Portions derived, with permission, from the Cal Poly Policies, Standards, Guidelines, Procedures, and Forms.