OTS Security Policy

Table of Contents

  1. Overview and Purpose
  2. Roles and Responsibilities
  3. Scope
  4. Policy Maintenance
  5. Policy
    1. Data Classification
    2. Acceptable Use
    3. Authentication
    4. Access and Account Management
    5. Disaster Recovery
    6. Change Management
    7. Computer Security Incident Response
    8. Electronic Data Retention and Destruction
    9. Physical Security and Clean Desk
    10. Third Party Management and System Acquisition
    11. Network Security
    12. Systems Security
    13. Risk and Security Assessment
    14. Information Security Awareness
  6. Non-Compliance
  7. Terms and Definitions
  8. Approval and Version Information

 

1. Overview and Purpose

Tennessee State University (TSU, the University) has established this information security policy to provide security guidance and directive to its users, including students, faculty and staff, and vendor / third party personnel. Information security can be defined as the measures that protect the confidentiality, integrity, and availability organization’s data and information systems. TSU intends to implement security measures that protect the data of students and employees, as well as ensure the ongoing success of its mission.

As a policy, this document defines high-level mandates critical to reducing security risks across the University, but does not proscribe specific controls or procedures (which can be found in TSU’s Security Standards). While the Office of Technology Services (OTS) will audit and facilitate validation for compliance with policy, TSU users and data owners are ultimately responsible and accountable for upholding the mandates described herein.

2. Roles and Responsibilities

I. Data Owner – The individual granted administrative control over a data or information asset. The data owner is typically a senior leader who understands how the data is used in the organization. Data owners are charged with classifying the data based on sensitivity, value, and confidentiality. This judgement determines who can view or manipulate the data, and well as the type of controls implemented to protect it.

II. Data Custodian – The individual charged with administering the data, the systems that support it, and the security controls requested by the data owner. They may help guide the data owner to an appropriate level of access and controls for a data asset. At TSU, most data custodians work in the Office of Technology Services (OTS).

III. Data User – An individual authorized by the data owner to access a data asset. Almost all students, employees, and vendor / third party workers at TSU are data users. Data users play a critical role in keeping TSU secure and the University expects them to comply with policy as well as report suspicious events that could indicate a security incident or breach.

3. Scope

This policy applies to:

a)       All data owned or managed by TSU

b)      All systems and infrastructure processing or storing TSU data

c)       All TSU students, employees, third party / vendor workers, and visitors accessing TSU data, systems, or infrastructure, whether electronically or physically

4. Policy Maintenance

The Chief Information Officer (CIO) and the Chief Information Security Officer (CISO) must review and approve information security policy at least once every year. The President of TSU shall ratify any resulting modifications to policy.

<Return to Table of Contents>

5. Policy

5.1 – Data Classification

The University classifies all data based on its value, sensitivity, and regulatory considerations. Classification determines how data is collected, stored, protected, and destroyed or wiped. TSU defines four categories of data:

Category

Description

Examples

Public

Data made available (intentionally) for public consumption.

- Brochures for prospective students, alumni, or parents

- Marketing materials

- Phone and email of customer / student facing university employees (e.g., the admissions office)

- Materials whose release to the general public would not harm the University’s mission or endanger student or employee privacy

Protected

Data that should be kept private, but which would not severely and directly endanger the university’s mission, student / employee privacy, or violate regulatory or compliance restrictions if released.

- Emails and phone numbers of faculty or staff who should not be readily accessible to the public

- Departmental procedures or diagrams (not containing restricted or highly sensitive information)

-  Academic materials (papers, PowerPoints, etc.) produced by a TSU student or teacher

- Employee or user IDs

Restricted

Data that when released or lost could damage TSU’s standing among other universities or otherwise result in a less competitive collegiate profile.

- Proprietary research

- Strategic plans

- Student transcripts

- Audit results

Highly Sensitive

Data uniquely identifying students or employees and endangering their privacy or financial well-being.

- Protected Health Information (PHI)*

- Financial data (including bank numbers and credit / debit card numbers)

- Personally Identifiable Information*

- Data that when disclosed in an unauthorized manner would subject the university to fines related to regulatory or compliance standards, including HIPPA, PCI DSS, and GDPR

- Passwords in University systems

PII – Any combination of data that could uniquely distinguish or trace an individual’s identity, including (but not limited to): name, social security number, date and place of birth, mother’s maiden name, or biometric records. (Source: NIST Special Publication 800-122).

PHI – Any element of a patient’s medical record or payment history that can be uniquely linked to a specific individual. HIPPA regulation identifies 18 record types that, when linked together so as to identify a specific individual, constitute PHI. Please refer to hipaajournal.com/de-identification-protected-health-information for a complete list of identifiers.

5.2. Acceptable Use

Users are expected to operate TSU information technology (IT) assets and data for approved, work related purposes. The following uses of TSU assets and data are not approved and can result in punishment up to termination of employment:

  1. Browsing websites with inappropriate content (pornography or illegal activity such as drugs or gambling)
  2. Performing network or software scans without the approval of the Office of Technology Services
  3. Downloading software or tools that are not approved by OTS
  4. Modifying system, computer, or application settings without prior approval from the owners or OTS
  5. Attempting to access systems for which authorization has not been given, whether they are TSU owned or owned by an external party
  6. Downloading and / or using key loggers, password crackers, sniffers, or any other tool to compromise or crack passwords without explicit approval from OTS
  7. Using University technology for inappropriate or abusive communication
  8. Setting up servers, applications, or networks without explicit approval from OTS
  9. Using University IT assets, data, or systems for personal profit or commercial purposes
  10. Uploading TSU data to external, unapproved applications, websites (e.g., Dropbox, Google Drive, etc.), or using personal email accounts to conduct business
  11. Taking action to deny services for TSU users (i.e. denial of service attacks)

5.3 – Authentication

Access to the University’s private networks, technology, and software must be secured with a username and password unique to each employee. Accounts should never be shared among users, since shared use inhibits attribution. Software and device default passwords should be changed as quickly as possible. Multiple factors of authentication (key fob, biometrics, smart card, etc.) should be considered for users accessing University networks or systems remotely.

5.4 – Access and Account Management

Access to TSU networks and systems must be granted via a unique account(s) linked to a specific user. Access to University networks and systems should be granted on a least privilege model, wherein users are granted only the access required to perform their job duties. Wherever possible, system and network permissions should be bundled into “roles” mapping to job duties. This model of access provisioning, known as role-based access control (RBAC) allows for easier access administration and standardization of access across similar jobs.

All network and system access must be approved by the user’s supervisor and the data owner. Access must be terminated in a timely manner upon employee termination, change of job role, end of contract or service with vendor, or any other event that renders any part of the user’s access unnecessary. Permissions assigned to individual accounts, as well as groups / roles with permissions assigned to them, should be reviewed periodically by the user’s supervisor or data owner to determine if the access remains appropriate and modified as needed.

5.5 – Disaster Recovery

OTS must work with University officials to develop a Disaster Recovery Plan (DRP) to ensure the availability of systems supporting critical processes in the event of natural or man-made disaster. The DRP should be derived from the Business Continuity Plan, and must list the IT systems and infrastructure supporting critical processes (as identified by the University). The DRP must then detail how these systems will be made available within a University-designated Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Further, the DRP must designate roles and responsibilities for disaster scenarios and include the contact information of responsible parties. Finally, an offsite, dedicated disaster recovery center must be maintained.

The DRP must be tested periodically. The results of the test must be recorded and used to modify the plan and/or the University’s recovery capabilities to ensure adherence to the University’s RTO and RPO.

<Return to Table of Contents >

5.6 - Change Management

Changes to university applications must go through a formal change management process that ensures sufficient testing and approvals before implementation to a production environment. Separation of duties (SoD) should also be enforced between testers, approvers, and implementers.

5.7 – Computer Security Incident Response

All TSU users are expected to report suspected indicators of compromise (IoC) to OTS. In addition, OTS must monitor TSU’s systems, networks, and electronic data for IoCs. OTS must triage suspected IoCs; confirmed IoCs – known as incidents - must be contained and remediated as soon as feasible. If an incident meets a defined risk threshold, OTS will initiate TSU’s Incident Response Plan, which may result in the involvement of one or more stakeholders (media relations, legal, HR, law enforcement, Ellucian Global Information Security, etc.) based on remediation and legal requirements. OTS’ incident responders are required to document both potential and confirmed incidents and provide the results to the CISO.

5.8 – Electronic Data Retention and Destruction

Requirements for the retention and destruction of digital data must be driven by the University’s broader data retention and destruction policies, standards, and guidelines. Using these guidelines, and with the assistance of Legal and HR, OTS shall develop and maintain requirements for retaining and disposing electronic data.

5.9 – Physical Security and Clean Desk

TSU users and workers are expected to exercise precaution to protect TSU facilities, data, and IT assets from unauthorized physical access. Achieving these ends requires:

  • University campus guests to follow the established guest access policy
  • Entry ways to non-public areas be locked and accessible only to authorized personnel
  • Keys or cards not to be shared among employees
  • Securing and supervision of workstations and other hardware hosting University data
  • Locking away sensitive data when leaving the work area, whether it is on paper or stored on an electronic device
  • Physically protecting IT assets, devices, cabling, and other infrastructure from tampering or theft and (as necessary) augmenting protection with monitoring capabilities, like security cameras

5.10 – Third Party Management and System Acquisition

All purchases of software or IT services must follow the Procurement Department’s formal purchasing process. In addition, OTS must be informed when any University department is considering contracting with an external organization to provide IT services or process TSU data. During the procurement process, OTS will assess the organization’s ability to comply with TSU security standards and identify mitigating controls that TSU must implement to ensure the security of TSU data or system availability. Whenever possible, the University must include security-specific service level agreements (SLAs) and right to audit clauses in contracts with third parties.

5.11 – Network Security

University networks must be architected to isolate traffic and systems based on criticality, confidentiality, and regulatory considerations. Isolation techniques include, but are not limited to, firewalls rules, ACLs, and network access control (NAC) software. Network devices (routers, switches, access points, etc.) should be configured to provide only required functions and secured based on vendor and leading practice guidelines. Firmware updates addressing security vulnerabilities should be promptly applied and unsupported network devices / software must be phased out in as soon as feasible. Finally, changes to device configurations, rulesets, and ACLs must be approved via the formal change management process.

5.12 – Systems Security

Systems, including operating and database management systems, should be secured according to their respective hardening baseline, as created by OTS leveraging best practices and vendor recommendations. All systems should be configured to use the minimum number of services, modules, or packages to meet business requirements. System updates/patches addressing security vulnerabilities should be promptly applied and unsupported systems must be phased out in as soon as feasible. Based on data classification, data owners and custodians must consider augmenting system security with encryption, whether for data in-transit or at-rest. Finally, changes to critical system configurations or images must be approved via the formal change management process.

5.13 – Risk and Security Assessment

OTS (or a qualified third party) must conduct periodic security assessments to determine if users are following IT policies and standards, University applications, systems, and infrastructure are secured to meet University standards, and if existing University policies and standards address technology risks.

5.14 – Information Security Awareness

OTS is responsible for administering the University’s information security awareness program. The program must include multiple methods for teaching users their role in identifying and preventing threats to the confidentiality, integrity, and availability of TSU’s systems and data. Methods for training users may include, but are not limited to: posters and brochures, presentations and seminars, simulations, and video-based trainings.

<Return to Table of Contents>

6. Non-Compliance

University employees and contractors found to be violating this policy may be subject to recourse, up to and including termination. Third parties found to be violating this policy may be found in breach of contract and subject to recourse as defined therein.

7. Terms and Definitions

  1. Confidentiality – Security rules and settings that restrict data and system usage to appropriate individuals
  2. Integrity – Security rules and settings that ensure data remains accurate and systems are used as intended
  3. Availability – Security rules and settings that ensure data and systems remain accessible
  4. Third Party – Any external entity involved in TSU’s relationship with its students. This includes, but is not limited to, vendors, government agencies, and contractors
  5. IT assets - TSU-owned data, systems, and hardware.
  6. Indicator of Compromise – Anomalous system or network activity that could indicate a computer intrusion. Includes, but is not limited to: loss of system functions, high traffic volume, downed or unresponsive sites, virus signatures, and pop ups claiming that your PC is infected
  7. Recovery Time Objective - the duration of time within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity
  8. Recovery Point Objective - the maximum period of data that can be lost from an IT service without unacceptable consequences regarding business continuity

8. Approval and Version Information

5/31/2018 – First draft

<Return to Table of Contents >

 

 

 

 






webpage contact:
CIT