Information Security Controls Standard

Title

University of North Carolina at Chapel Hill Information Security Controls Standard

Introduction

Purpose

This standard sets the base security controls for Information Technology (IT) systems at the University of North Carolina at Chapel Hill ("UNC-Chapel Hill" or "University"). Units within the University may apply stricter controls to protect information and systems in their areas of responsibility.

Scope

Every person connected to the University and all University units.

If people use a personal device for University business, the owner of the personal device must make sure the personal device meets the same security standards as University-owned devices. University units may help people follow these controls or get exceptions when the controls can’t be met on a personal device used for University business. The University unit still has responsibility for University data no matter where it exists. Personal devices create additional risks.

Standard

The University sets these required protections for IT to follow the law and other University policies.

Everyone connected with the University must follow at least these rules. Some units may have stricter rules for the people in those units or the systems those units are responsible for.

Every year, the University's Information Technology Services (ITS) Information Security Office (ISO) will select a priority set of "key controls." Heads of University units must take part in an annual process to confirm that they are taking particular care with at least those key controls.

Be sure to understand all controls that might apply to a system. For example, if a server is storing Tier 2 data in a database, the server must follow controls for a server with Sensitive Information and the database application controls. These Standards set the basic requirements. Anyone responsible for a system may apply more or stricter controls for specific needs.

In the charts below, notations are as follows:

• Category A. This control must be used unless the ISO approves an exception in writing.
• Category B. Unless there is a strong reason, like a technical obstacle, this control must be used. If the control is not used, you can make the exception yourself. Be prepared to document any ways you tried to use the control, any reasons it isn’t in place, and any extra controls you used instead.
  • Consult your Information Security Liaison (ISL), help.unc.edu, or other campus resources for help if needed.
  • For items listed only as "B" you may be asked by the ISO to document your justification for not using the control, including any different controls used instead.
  • If the item has an asterisk ("B*") then a systems administrator or someone else responsible for the system must document the justification for not using the controls or any different controls being used instead. Consult your ISL for advice before deciding that an item can’t use a required control. Documentation of the exception must be done before the system goes into Production or holds any Tier 2 or 3 information. Store documentation in a secure location where administrators and supervisors for the system can find it.
• Category C. These items are recommended. Please try to use them.
• Blank: Some controls do not apply to the category. But if a control is technically possible, consider it.
• MC: Mission Critical. The control applies differently to Mission Critical systems than to other systems in the same category.
• SI: Sensitive Information. Tier 2 or 3 in the UNC-Chapel Hill Information Classification Standard. The control applies differently to systems that work with Sensitive Information than to other systems in the same category. The chart also notes specific Tier 2 or Tier 3 instead of “SI” in some cases where the control is different based on the specific Tier.

See descriptions of controls following the tables.

Security Controls

University activities performed under contract with the United States Department of Defense have specific security requirements. These projects must be confined to a secure computing enclave approved by the ISO. These secure computing enclaves must apply at least all security controls in this Standard shown for Tier 3 information and any ISO-approved combination of controls and plans of action and milestones (POA&M). Exceptions to this requirement must be approved by the Chief Information Security Officer (CISO). 

Data

Security controls exist to protect University Data (and technology assets). Regardless of where University data is, the following controls apply. NOTE: Public records, eDiscovery, and other requirements apply to personal devices as well as University technology. Data must be purged from a personal device when your authorization to have that data has ended. University data should be purged from any device when the need for it ends, always following records retention and other requirements.  

Use resources to prioritize controls protecting Tier 3 (more sensitive) data before Tier 2, 1, or 0 (less sensitive) data. Follow University storage guidelines to store Tier 2 and 3 data (and all University data) in approved locations. Do not leave Sensitive data visible on unattended desks or screens. Use physical controls to protect all Sensitive Information. Do not publish Sensitive Information (on social media or web sites for example) or share it anywhere unauthorized people might access it. Use your best judgment to protect Sensitive Information. 

Control Descriptions (See Charts above)

24/7 Monitoring: Automated monitoring to check whether systems are working or not, with escalating notifications when systems are down. 

2-Step Verification or Multi-factor Authentication: Requiring multiple methods to confirm that system requests like login attempts are from who they claim to be from. Methods include: 

• "Something you have" (like an RSA token or your phone),
• "Something you know" (like a PIN or a password), and
• "Something you are" (checking biometric data like a fingerprint or retinal scan).

Multi-factor is recommended for all privileged accounts.

Account Lock-out:

An information system must work to inhibit password guessing and similar attacks. For example, the system may:

• automatically block or slow remote connections or logins associated with abuse, and/or
• watch for a specific number of failed logins within a window of time and lock the account for a proper amount of time.

For example, within a five-minute window, 10 failed attempts would lock the account for five minutes.

Manage system-integration considerations carefully when setting up account lock-out controls.

Application Time-out: Application owners should set up a time-out considering the risks, specific problems, and the environment of their system.

Backup: Use backups that can be restored to protect University Information, which is an asset, from many kinds of risks. Test backups sometimes to make sure they work. Full or partial backups are ok if the system information can be restored. Ask your local IT support for laptop and desktop backup options. Consult your ISL or the ISO if you have questions about good backup practices.

Campus Filtering: Separating parts of a network into "segments" to keep computers separate from each other. Segments may be created using VLAN access control lists (ACLs) or firewall. (This control is provided by the University. Please contact your local IT support if you have questions.)

Detailed Auditing for Access: Store detailed logs that document electronic access to Sensitive Information for the time listed in the applicable records retention schedule item. Generally, these are kept for 90 days or until they reach 250MB. Review periodically or set alerts to detect unauthorized access. Some systems, like those holding protected health information (PHI), may have specific higher requirements for logging. Follow the longest time requirement to keep the logs.

Encryption (File/Folder or Partition): Encoding a specific file, folder, or partition that holds important information (protected health information (PHI) or personally identifiable information (PII) for example) in a way that it can only be used by someone authorized. If full-disk encryption is used for offline media (tape or disk for example) then file or partition encryption is optional.

Formal System Administrator Initiative (SAI) Training: ITS offers this course. The course is required for anyone on campus who has elevated privileges on a server that lets them perform administrative tasks like changing the system configuration settings or managing user access controls.

Full-Disk Encryption: Converting data on an entire hard drive (or something like a hard drive) into a format that cannot be understood by anyone unless they have the key to decrypt, or "undo" the conversion. Encryption must follow current best practices. If an application automatically encrypts all non-Operating System files without a person having to interact to make it happen, that satisfies the full-disk encryption requirement.

NOTE: Some systems may keep ("cache") information they process in files that stay on the system when you believe the information is gone. Keep that in mind when deciding whether this control is needed.

Host-based Firewall: Software firewall running on a single computer ("host") that can restrict incoming and outgoing network traffic to protect just that computer. When host-based firewall is not a technical possibility, VLAN ACLs or network firewall may be used as alternatives.

Input/Output (I/O) Validation: Good application-coding technique especially for web applications that prevents unintended use or misuse of the application. For example, I/O validation prevents attackers from inserting malicious commands.

Internet Filtering (Special Router Access Control Lists (ACL) or Campus Firewall): Tools to protect networks used for University work from traffic coming from the Internet. Special router access control lists (ACLs) and the campus firewall are provided by ITS to meet this requirement. People using off-campus systems and networks must make sure they have Internet filtering in place. Contact your local IT support or ISL if you have any questions.

Intrusion Prevention System (IPS): Systems that watch network or computer activities to spot malicious activity. An IPS will log information, try to stop the activity, and report what it has found. The University implements various IPSs, including web application firewalls. Please contact your local IT admin or ISL if you have questions.

ITS Security Awareness Training for Computer Users (or equivalent): People with an Onyen who use University systems must take the University’s basic security awareness training annually. You should see the reminder when you change your Onyen password.

Least Functionality: Set up systems to only do things they need to do. Prevent use of unnecessary or insecure functions, ports, protocols, and services. For example, turning off Trivial File Transfer Protocol (TFTP) or peer-to-peer file sharing protocols such as BitTorrent are examples of least functionality.

Least Privilege: Set up user, application, and system accounts to access the information and resources they need to perform their functions. Only allow Local Admin privileges if they are needed.

Local System Event Logs: Event logs are special files that record significant things that happen on a computer, such as when a person logs on or when a program has an error. Detailed audit logs that document electronic access to Sensitive Information should be stored for the duration shown in the records retention policy item that applies, or as needed for regulatory compliance (including HIPAA compliance). Generally, those are kept for 90 days or 250MB. It is best to review logs periodically or set alerts on logged information.

Managed and Monitored Malware Protection: Anti-malware systems run and monitored by an IT unit satisfy this control. ("Centralized" is not required for UNIX/Linux systems.) These applications have alerting and reporting capabilities. If it isn’t possible to automate this protection, justify that non-compliance. People using host-based (only on the computer), non-managed malware protection can comply by at once reporting any notifications of possible malware from the application. The University supplies various Malware Protection Systems on campus networks. Please contact your local IT admin or ISL if you have questions.

Network Session Timeout: An application or system should end an existing connection or session if it is inactive for more than 15 hours.

Onyen/Shibboleth and/or Federated Authentication: Use the Onyen to authenticate people to systems you control whenever that is possible. 3rd-party authentication such as Shibboleth, Azure Active Directory, or Central Authentication Service (CAS) is also strongly recommended for Web applications. LDAP is not recommended for authentication.

Password Policy Enforcement: Follow the Passwords, Passphrases, and Other Authentication Methods Standard unless you have an exception.

Patch Management (Automated Recommended): Installing updates to computers as often as needed and considering their importance to decide how soon an update is needed. It is best to automate patch management. Follow applicable policy, especially the Vulnerability Management Standard for Information Technology.

Remote Copy of System Event Logs: Copying system event logs to another place to protect them from tampering and to make reporting easier. Using "syslog" or another Security Information and Event Management (SIEM) system improves the ability to alert and report.

Risk Assessment:

Any system that contacts University Tier 2 or 3 data (Sensitive Information) or is considered Mission Critical by the unit responsible for it must have an ISO Risk Assessment. Systems that create, receive, keep, store, or send Tier 2/3 information qualify. An ISO Risk Assessment looks at potential threats and vulnerabilities of a system, its provider, or its use. An ISO Risk Assessment considers whether the information the system contacts could be exposed, changed, lost, or harmed in another way. For Mission Critical systems the ISO Risk Assessment also considers how reliable the system itself is expected to be. Existing systems must get an ISO Risk Assessment when there is a planned architecture change (on-premises to cloud for example) or if higher-tier data will be added. A periodic ISO Risk Assessment may be needed if a first assessment includes that requirement. The CISO may require an ISO Risk Assessment of any University system. Some risks found in an ISO Risk Assessment may need to be reduced. The ISO Risk Assessment report will give these directions. HIPAA risk analysis for systems holding electronic protected health information (ePHI) will be conducted periodically.

The ISO decides the needed scope of any ISO Risk Assessment and may decide that one is not needed or may be done later. (Which satisfies this requirement.) Independent third-party assessments (like the Service Organization Controls (SOC) 2 Type 2) or other alternate security risk assessments will reduce the time to complete an ISO Risk Assessment if those third-party assessments are available. If the time needed to perform an ISO Risk Assessment will have a big impact on operations, appeals can go to the Office of the Chief Information Officer (CIO).

Screen-lock: Each logged-in user account must be locked out automatically after no more than 30 minutes of inactivity.

Secure Configuration: Use best practices configuring operating systems and applications. Disable unused ports or other means of access, change default passwords, and configure in ways that reduce risk and allow needed functions. The U.S. National Institute of Standards and Technology (NIST) has guidance on secure configuration on their "National Checklist Program" webpage. See Also: Least Functionality.

Secure Disposal:

Depending on what will be done with media needing disposal and what kind of media it is, disposal procedures may be different. Reuse, repair, replacement, and removal are different situations.

 All media that stores University information must be properly sanitized before the person responsible disposes of it. It is ok to transfer media within the same University unit without sanitization if care is taken to be sure that only authorized people can access the data by ordinary means.

The sanitization of media is done by overwriting data or physically destroying the media.

Overwriting requires three overwriting passes and a verification pass. A variety of software can properly perform this function including Pretty Good Privacy, Eraser, and KillDisk.

Destruction requires damaging the media enough to make it unusable in any way it would normally be read. University units must keep documentation of sanitization of hard drives. Label equipment chosen for surplus or other re-use saying that the hard drive has been properly sanitized.

If equipment is given to a third party for repair or data recovery, they must have an agreement with the University to address data management and disposition. (ex: master service agreement with corresponding "Business Associate Agreement" if PHI is on the device).

Damaged or non-working media that cannot be overwritten (Including SSD and USB devices) must be destroyed. Secure shredding of drives is available from the UNC Surplus Property warehouse (919-962-2134). More guidance is available at help.unc.edu by searching "Electronic Media Disposal."

Secure Physical Access: Use measures proper to the system or media (a USB device for example) to allow only authorized people to get physical access to the system or media and generally protect the system or media. Specific strategies include:

• Badge access controls,
• Key management,
• Logging who comes into an area,
• Fire detection and suppression,
• Temperature and humidity controls,
• Emergency lighting,
• Water damage protection,
• Emergency power and shutoff mechanisms,
• Screen protectors that blur a display with Sensitive Information, and/or
• Positioning systems to reduce exposure of Tier 2 or 3 Sensitive Information.
  • Don’t locate sensitive workstations in lobbies or other lightly-secured areas without more controls such as a security cable, encryption, etc.

Sensitive Field Encryption: Also known as "application-level." This type of encryption happens within the application itself. This keeps specific information stored in a database separate from its encryption keys and secure when the data is stored. Encryption keys are on the application server, and the encrypted data is in the separate database.

Service Accounts: Also known as System or Device accounts, Service Accounts are usually not associated with a person. These accounts are used to run IT “services” for applications (for example: Web services, database services, or an account created to run a specific application without a person involved.) Other service accounts are built into operating systems or applications (accounts like "root," "system," "manager," "operator," or "admin").

Service accounts must only be used for system services. Do not use a person’s account or a regular "user" account to run system services. People must not log in using a service account other than to support the specific service or system. Configure systems to prevent remote logins to service accounts wherever it is technically possible.

Service accounts may be managed by more than one person. Reviewing logins and uses of service accounts is strongly recommended. Administrators should know whether a service account can be used remotely on their system or application. Keep the number of systems sharing the same service account and credentials (password or other method of logging in) low. Consider using other controls to compensate for service account use.

System Contact: The ITS Control Center keeps responsible people's contact information (both "Business Day," and "Off Hours") for registered computers ("hosts"). The Control Center will contact people when an incident involves that host. Supply contact and escalation information to the Control Center via help request and keep it up to date.

Vendor-Supported Application: The application vendor or an alternate source (open-source community, in-house developer for example) must still be publishing security updates for the application version being used.

Vendor-Supported Operating System: The Operating System vendor or an alternate source (open-source community, in-house developer for example) must still be publishing security updates for the version in use.

VPN Software for Remote Access: A system that protects information across networks. Intended for people accessing Tier 2/3 University information remotely.

Use VPN software supplied or approved by ITS Network Services for remote connections over unsecure networks.

Vulnerability Scan (Operating System, Web, Database): Follow the Standard for Vulnerability Management.

• Operating system vulnerability scans run with administrator access at least monthly.
• Web application scans do not have to be run with admin permissions).
• Scanning may be done every six months for web applications, or annually if a risk-assessed web-application firewall is in use.
• Database applications existing behind network firewalls and using a host-based firewall may scan every six months.
• Alternative controls to Web and Database vulnerability scans may be used with documented reasons.
• Vulnerability scanning is only needed for workstations and laptops storing Sensitive Information, not for those that only access the Sensitive Information. Workstations/Laptops existing behind a University firewall, with host-based firewall enabled, and attached to the Active Directory domain may scan annually rather than monthly. NOTE: Some systems may hold Sensitive Information they process in files that stay on the system. Consider that when deciding whether vulnerability scanning is needed.

Warning Banner for Services Requiring Authentication:

An approved system-use notification message displayed on a computer screen prior to allowing the user to access the system. The message includes privacy and security notice following applicable law or other compliance requirements, and at least notifies users that:

• The System is a UNC-Chapel Hill system,
• Unauthorized access may result in penalties, and
• Responsibilities the user may have for use of the system.

Note: This control does not apply to personal devices.

Exceptions

Because the University has so many different and often unique needs, units use other controls to make up for those listed that do not work in their environment. The goal is proper security risk management. Units, data stewards, and information security staff work together to figure out and document needed controls for difficult environments.

In most cases, unit staff will be the subject matter experts for appliances, single-purpose systems, and for their business requirements. The ISO is responsible for information security practices and provides expertise in that area.

When a unit requests a control exception and supplies good background and reasoning, open communication will result in a documented exception.

Process

Submit exceptions for approval to the CISO or delegate via help request Exceptions may be requested on a device-by-device basis, or with a single request covering multiple identical systems with the same reasons for exception ("Exemplars"), or with a single request covering a whole system for the same set of compensating controls.

An exception review will consider:

• Alternate security controls,
• Impact on mission,
• Recommendations about a specific vulnerability,
• Technical obstacles,
• Operational obstacles, and
• Any other information provided in the request.

Usually just using cost as a justification would mean the cost would be entirely prohibitive. Data governance requirements will also figure in exceptions.

While reviewing an exception request, the CISO or delegate will likely extend the timelines applying to security requirements. However, this depends on the risk to the University and is at the CISO's discretion. Extensions must be in writing.

If the CISO or delegate does not grant an exception, the department may appeal to the CIO. The CIO may ask that the unit’s Department Head be involved. If the result would be removal of a system from the network or other high-impact action, the CISO will seek approval from the CIO to take that action.

Approved Blanket Exceptions

Encryption is not required for laptops that are accessing Sensitive Information exclusively through an ISO-approved secured Virtual Desktop Interface (VDI) (e.g., CITRIX or other approved VDI).

Security controls written for certain kinds of devices may not make sense for cloud services. If a control cannot be applied to a cloud system, it may be skipped under some circumstances. Follow ISO guidance on storage of Sensitive Information in Microsoft 365 and other cloud services (see references below).

Definitions

Covered System: Computing device used for University Business.

Information Security Office (ISO) Risk Assessment: Risk Assessment or analysis is the process of identifying, prioritizing, and estimating risks. Information Security Risk Assessment looks at threats and vulnerabilities and considers risk reduction from security controls planned or in place.

Mission Critical: A system so critical to the mission of the UNC-Chapel Hill business unit that any incident requires immediate response. If a system is considered Mission Critical by the department (which makes that decision), then they will have supplied contact and escalation information in advance of any incident or outage. Heightened information security requirements apply to a mission critical system. The goal is to keep the resource available for use. If a unit does not choose a resource as mission critical, that resource falls to a lower priority to bring services back if there is an incident or outage.

Sensitive Information: Information classified as Tier 2 or Tier 3 in the UNC-Chapel Hill Information Classification Standard.

Related Requirements

External Regulations and Consequences

• Health Insurance Portability and Accountability Act (HIPAA)
• Family Educational Rights and Privacy Act (FERPA)
• N.C. General Statute, Chapter 75, Article 2A - North Carolina Identity Theft Protection Act (NCID)
• N.C. General Statute, Chapter 132 - Public Records
• National Institute of Standards and Technology (NIST) 800-53: Security and Privacy Controls for Information Systems and Organizations
• National Institute of Standards and Technology (NIST) 800-171: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations

Compliance

Failure to follow this policy may put University information assets at risk and may have disciplinary consequences for employees, up to and including termination of employment. Students who do not adhere to this policy may be referred to the UNC-Chapel Hill Office of Student Conduct. Contractors, vendors, and others who do not adhere to this policy may face termination of their business relationships with UNC-Chapel Hill.

Violation of this policy may also carry the risk of civil or criminal penalties.

University Policies, Standards, and Procedures

• Information Security Policy
• Information Classification Standard
• Vulnerability Management Standard for Information Technology
• Office 365 Data Sharing Guidance
• See available Malware protection packages
• Web Single-Sign-On

For more information on Sensitive Information go to help.unc.edu and search for "Sensitive Information."

Contact Information

Primary Contact

UNC ITS Information Security Office

• Email: help.unc.edu
• Phone: 919-962-HELP

Other Contacts

ITS Policy Office

• Email: its_policy@unc.edu

Important Dates

• Effective Date and title of Approver: (Prior document, Information Security Policy)
  1. Effective Date: 3/6/2010
  2. Approver: Chief Information Officer
  3. Revised Date: 6/30/2011
  4. Revised by: Chief Information Officer Substantive Revisions: Unknown
  5. Effective Date: 1/20/2016 (Information Security Controls Standard)
  6. Approver: Chief Information Security Officer
  7. Substantive Revisions: The standards contained in this document were previously laid out in the Information Security Controls Policy. These standards were moved into their own document superseding all related controls sections of the Information Security Controls Policy.
• Revision and Review Dates, Change notes, title of Reviewer or Approver:
  1. Last Revised: 10/25/2017
  2. Revised by: Chief Information Security Officer
  • Substantive Revisions: Incorporating Electronic Media Disposal (superseding existing Electronic Media Disposal Standard), adding application and network session timeout controls, removing mainframe controls, altering Risk Assessment control, addition of "advisory" items, added data classification tiers for some controls, language clarifications throughout. Adjustments to control levels throughout.
• Subsequent dates in PolicyStat log.