NIC Policy 3.08.03 Data Stewardship, Security and Protection Guidelines

These guidelines are provided to support Policy 3.08.03 Data Stewardship, Security and Protection. These guidelines further define roles and responsibilities, classification of data, and security controls.

These guidelines are provided to support Policy and Procedure 3.08.03 Data Stewardship, Security and Protection. 

Roles and Responsibilities

Data Classification

Predefined Types of Restricted Data

Data Collections

Cloud Storage of Restricted Data

Reclassification of data

Calculating Data Classification

Security Controls

Application Security

Disaster Recovery

Electronic Access Control

Encryption

Information Systems Security

Media Sanitation and Disposal

Network Security

Physical Security

Cloud Storage - General Provisions

 

Roles and Responsibilities:

The North Idaho College Information Data Stewardship Policy (3.08.03) states that, “Individuals who create, collect, handle, or manage data are responsible for complying with the Data Stewardship roles and responsibilities for their identified role (Data Steward, Data Custodian, or User) as defined by the Data Stewardship Policy”.  These roles and responsibilities are defined as follows:

Data Steward

A Data Steward is a senior-level employee of North Idaho College who oversees the lifecycle of one or more sets of Institutional Data.  Responsibilities of a Data Steward include the following:

a.         Assigning an appropriate classification to Institutional Data.

            All Institutional Data should be classified based on its sensitivity, value and criticality to North Idaho College.  The college has adopted three primary classifications:  public, sensitve and restricted/confidential. 

b.         Assigning day-to-day administrative and operational responsibilities for Institutional Data to one or more Data Custodians.

            Data Stewards may assign administrative and operational responsibility to specific employees or groups of employees.  A Data Steward could also serve as a Data Custodian or User.  In some situations, multiple groups will share Data Custodian responsibilities.  If multiple groups share responsibilities, the Data Steward should understand what functions are performed by what group.

c.         Approving standards and procedures related to day-to-day administrative and operational management of Institutional Data.

            While it is the responsibility of the Data Custodian to develop and implement operational procedures, it is the Data Steward’s responsibility to review and approve these standards and procedures.  A Data Steward should consider the classification of the data and associated risk tolerance when reviewing and approving these standards and procedures.  For example, high risk and/or highly sensitive data may warrant more comprehensive documentation and, similarly, a more formal review and approval process.  A Data Steward should also consider his or her relationship with the Data Custodian(s).  For example, different review and approval processes may be appropriate based on the reporting relationship of the Data Custodian(s).

d.         Determining the appropriate criteria for obtaining access to Institutional Data.

            A Data Steward is accountable for who has access to Institutional Data. This does not imply that a Data Steward is responsible for day-to-day provisioning of access. Provisioning access is the responsibility of a Data Custodian and the information technology department. A Data Steward may decide to review and authorize each access request individually or a Data Steward may define a set of rules that determine who is eligible for access based on business function, support role, etc. For example, a simple rule may be that all students are permitted access to their own transcripts or all staff members are permitted access to their own health benefits information. These rules should be documented in a manner that allows little or no room for interpretation by a Data Custodian.

e.         Ensuring that Data Custodians implement reasonable and appropriate security controls to protect the confidentiality, integrity and availability of Institutional Data.

            A Data Steward will often have their own security requirements specified in contractual language and/or based on various industry standards.  Data Stewards should be familiar with their own unique requirements and ensure Data Custodians are also aware of and can demonstrate compliance with these requirements.  The Information Technology Department can assist with mapping controls mandated by contract(s) or industry standards.

f.          Understanding and approving how Institutional Data is stored, processed and transmitted by the College and by third-party Agents of the College.

            In order to ensure reasonable and appropriate security controls are implemented, a Data Steward must understand how data is stored, processed and transmitted. This can be accomplished through review of data flow documentation maintained by a Data Custodian. In situations where Institutional Data is being managed by a third-party, the contract or service level agreement should require documentation of how data is or will be stored, processed and transmitted.

g.         Defining risk tolerance and accepting or rejecting risk related to security threats that impact the confidentiality, integrity and availability of Institutional Data.

            Information security requires a balance between security, usability and available resources.  Risk management plays an important role in establishing this balance.  Understanding what classifications of data are being stored, processed and transmitted will allow Data Stewards to better assess risks.  Understanding legal obligations and the cost of non-compliance will also play a role in this decision making.  Both the Information Technology Department and the Legal Counsel can assist Data Stewards in understanding risks and weighing options related to data protection. 

h.         Understanding how Institutional Data is governed by North Idaho College policies, state and federal regulations, contracts and other legal binding agreements.

            Data Stewards should understand whether or not any North Idaho College policies govern their Institutional Data. For example, the Information Security and Protection Policy governs the protection of all Institutional Data. Other policies exist to help govern financial information, health information, etc. Similarly, Data Stewards are responsible for having a general understanding of legal and contractual obligations surrounding Institutional Data. For example, the Family Educational Rights and Privacy Act (“FERPA”) dictates requirements related to the handling of student information.

Data Custodian

A Data Custodian is an employee of North Idaho College who has administrative and/or operational responsibility over Institutional Data.  In many cases, there will be multiple Data Custodians.  An enterprise application may have teams of Data Custodians, each responsible for varying functions.  A Data Custodian is responsible for the following:

a.         Understanding and reporting on how Institutional Data is stored, processed and transmitted by the college and by third-party Agents of the college.

            Understanding and documenting how Institutional Data is being stored, processed and transmitted is the first step toward safeguarding that data.  Without this knowledge, it is difficult to implement or validate safeguards in an effective manner.  One method of performing this assessment is to create a data flow diagram for a subset of data that illustrates the system(s) storing the data, how the data is being processed and how the data traverses the network.  Documentation should exist and be made available to the appropriate Data Steward.

b.         Implementing appropriate physical and technical safeguards to protect the confidentiality, integrity and availability of Institutional Data.

            Contractual obligations, regulatory requirements and industry standards also play in important role in implementing appropriate safeguards.  Data Custodians should work with Data Stewards to gain a better understanding of these requirements.  Data Custodians should also document what security controls have been implemented and where gaps exist in current controls.  This documentation should be made available to the appropriate Data Steward.

c.         Documenting and disseminating administrative and operational procedures to ensure consistent storage, processing and transmission of Institutional Data.

            Documenting administrative and operational procedures goes hand in hand with understanding how data is stored, processed and transmitted.  Data Custodians should document as many repeatable processes as possible.  This will help ensure that Institutional Data is handled in a consistent manner.  This will also help ensure that safeguards are being effectively leveraged.

d.         Provisioning and de-provisioning access to Institutional Data as authorized by the Data Steward.

            Data Custodians are responsible for provisioning and de-provisioning access based on criteria established by the appropriate Data Steward.  As specified above, standard procedures for provisioning and de-provisioning access should be documented and made available to the appropriate Data Steward.

e.         Understanding and reporting on security risks and how they impact the confidentiality, integrity and availability of Institutional Data.

            Data Custodians should have a thorough understanding of security risks impacting their Institutional Data.  For example, storing or transmitting sensitive data in an unencrypted form is a security risk.  Protecting access to data using a weak password and/or not patching a vulnerability in a system or application are both examples of security risks.  Security risks should be documented and reviewed with the appropriate Data Steward so that he or she can determine whether greater resources need to be devoted to mitigating these risks.  This Information Technology Department can assist Data Custodians with gaining a better understanding of their security risks as well as aid in the provisioning and de-provisioning of user access.  The information technology department will not provide access to institutional data without approval from the appropriate data steward or custodian.

User

For the purpose of information security, a User is any employee, contractor or third-party Agent of North Idaho College who is authorized to access Information Systems and/or Institutional Data. A User is responsible for the following:

a.         Adhering to policies, guidelines and procedures pertaining to the protection of Institutional Data.

            The Information Technology Department publishes various policies, guidelines, and procedures related to the protection of Institutional Data and Information systems. Business units and/or data stewards may also publish their own unique guidelines and procedures.  Information on requirements unique to your business unit or a system you have access to can be found by talking to your manager or system administrator.

b.         Reporting actual or suspected vulnerabilities in the confidentiality, integrity or availability of Institutional Data to a manager or the Chief Information Officer.

            During the course of day-to-day operations, if a data steward, data custodian, or user comes across a situation where he or she feels the security of Institutional Data might be at risk, it should be reported to the Chief Information Officer or helpdesk.  For example, if a User comes across sensitive information on a website that he or she feels shouldn’t be accessible, that situation should be reported to the Chief Information Officer or helpdesk.  Additional notifications may be appropriate based on procedures unique to a business unit or defined by a Data Steward.  It may be appropriate to notify a local security point of contact that will in turn coordinate with the Information Technology Department.

c.         Reporting actual or suspected breaches in the confidentiality, integrity or availability of Institutional Data to the Chief Information Officer and/or NIC helpdesk.

            Reporting a security breach goes hand in hand with reporting vulnerabilities.  Once again, it may be appropriate to notify a local security point of contact that will in turn coordinate with the Information Technology Department.  See policy and procedure 3.08.04 Computer Security Incident Response for more information.

 

Data Classification

Data classification, in the context of information security, is the classification of data based on its level of sensitivity and the impact to North Idaho College should that data be disclosed, altered or destroyed without authorization. The classification of data helps determine what baseline security controls are appropriate for safeguarding that data.  All institutional data should be classified into one of three sensitivity levels, or classifications:

A.        Restricted Data

            Any NIC institutional data that, if disclosed to unauthorized persons, would be a violation of federal or state laws, NIC policy, or NIC contractual obligations.  Any file or data that contains personally identifiable information may also qualify as restricted data.  The highest level of security is applied to this data classification.

B.        sensitve Data

            Any NIC institutional data that must be guarded due to proprietary, ethical, or privacy considerations and must be protected from unauthorized access, use, modification, transmission, or storage.A reasonable level of security is applied to this data classification.

C.        Public Data

            Any NIC institutional data to which the public is granted access, in accordance with NIC policy or standards.  A level of control is applied to this data classification to ensure appropriate use.

Predefined Types of restricted Information

The Information Technology Department has defined several types of restricted/confidential data based on state and federal regulatory requirements. They're defined as follows:

1.         Authentication Verifier

An Authentication Verifier is a piece of information that is held in confidence by an individual and used to prove that the person is who they say they are.  In some instances, an Authentication Verifier may be shared amongst a small group of individuals.  An Authentication Verifier may also be used to prove the identity of a system or service.  Examples include, but are not limited to:

• Passwords
• Shared secrets
• Cryptographic sensitve keys

2.         Covered Financial Information

Information that is protected under the Gramm-Leach-Bliley Information Guidelines.

3.         Electronic Protected Health Information ("EPHI")

EPHI is defined as any Protected Health Information ("PHI") that is stored in or transmitted by electronic media. For the purpose of this definition, electronic media includes:

Electronic storage media includes computer hard drives and any removable and/or transportable digital memory medium, such as magnetic tape or disk, optical disk, flash drive, or digital memory card.

Transmission media used to exchange information already in electronic storage media.  Transmission media includes, for example, the Internet, an extranet (using Internet technology to link a business with information accessible only to collaborating parties), leased lines, dial-up lines, private networks and the physical movement of removable and/or transportable electronic storage media.  Certain transmissions, including of paper, via facsimile, and of voice, via telephone, are not considered to be transmissions via electronic media because the information being exchanged did not exist in electronic form before the transmission.

4.         Export Controlled Materials

Export Controlled Materials is defined as any information or materials that are subject to United States export control regulations including, but not limited to, the Export Administration Regulations (“EAR”) published by the U.S. Department of Commerce and the International Traffic in Arms Regulations (“ITAR”) published by the U.S. Department of State. See the Office of Research Integrity and Compliance's FAQ on Export Control for more information.

5.         Federal Tax Information ("FTI")

FTI is defined as any return, return information or taxpayer return information that is entrusted to the NIC by the Internal Revenue Services. See Internal Revenue Service Publication 1075 Exhibit 2 for more information.

6.         Payment Card Information

Payment card information is defined as a credit card number (also referred to as a primary account number or PAN) in combination with one or more of the following data elements:

• Cardholder name
• Service code
• Expiration date
• CVC2, CVV2 or CID value
• PIN or PIN block
• Contents of a credit card’s magnetic stripe

7.         Personally Identifiable Education Records

Personally Identifiable Education Records are defined as any Education Records that contain one or more of the following personal identifiers:

• Name of the student
• Name of the student’s parent(s) or other family member(s)
• Social security number
• Student number
• A list of personal characteristics that would make the student’s identity easily traceable
• Any other information or identifier that would make the student’s identity easily traceable

See the NIC Academic Catalog section on Student Records, Confidentiality and FERPA for more information on what constitutes a Personally Identifiable Record.

8.         Personally Identifiable Information

For the purpose of meeting security breach notification requirements, PII is defined as a person’s first name or first initial and last name in combination with one or more of the following data elements:

• Social security number
• State-issued driver’s license number
• State-issued identification card number
• Financial account number in combination with a security code, access code or password that would permit access to the account
• Medical and/or health insurance information

9.         Protected Health Information ("PHI")

PHI is defined as "individually identifiable health information" transmitted by electronic media, maintained in electronic media or transmitted or maintained in any other form or medium by a covered component, as defined by HIPAA Policy. PHI is considered individually identifiable if it contains one or more of the following identifiers:

• Name
• Address (all geographic subdivisions smaller than state including street address, city, county, precinct or zip code)
• All elements of dates (except year) related to an individual including birth date, admissions date, discharge date, date of death and exact age if over 89)
• Telephone numbers
• Fax numbers
• Electronic mail addresses
• Social security numbers
• Medical record numbers
• Health plan beneficiary numbers
• Account numbers
• Certificate/license numbers
• Vehicle identifiers and serial numbers, including license plate number
• Device identifiers and serial numbers
• Universal Resource Locators (URLs)
• Internet protocol (IP) addresses
• Biometric identifiers, including finger and voice prints
• Full face photographic images and any comparable images
• Any other unique identifying number, characteristic or code that could identify an individual

PHI does not include education records or treatment records covered by the Family Educational Rights and Privacy Act (FERPA) or employment records held by the NIC in its role as an employer.

10.       Controlled Technical Information ("CTI")

            Controlled Technical Information means "technical information with military or space application that is subject to controls on the access, use, reproduction, modification, performance, display, release, disclosure, or dissemination".

Data Collections

Data Stewards may wish to assign a single classification to a collection of data that is common in purpose or function. When classifying a collection of data, the most restrictive classification of any of the individual data elements should be used. For example, if a data collection consists of a student’s name, address and social security number, the data collection should be classified as restricted/confidential even though the student’s name may be considered Public information.

Cloud storage of restricted data:

The following table shows which types of restricted/confidential data a user can store using an approved cloud storage service. Note that this only applies to enterprise accounts. Personal cloud storage accounts should not be used to store sensitve or restricted/confidential data (See policy and procedure 3.08.05 for more information). Note that this list is not comprehensive and only represents restricted/confidential data that has been identified by the Information Technology Department.  Other types of data may be considered restricted/confidential that are not listed here. When in doubt, consult with the appropriate data steward, the information technology department, or your supervisor prior to using the service.

Restricted Data	Usage	Details
Authentication Verifiers (e.g. passwords)	Must have approval from IT	As a general rule of thumb, users should avoid using cloud storage solutions to store passwords, shared secrets or encryption keys. While there may be use cases for using cloud services to store personal account passwords, such services should not be used for storing North Idaho College account passwords unless explicitly authorized.
Covered Financial Information	Consult with Data Steward	Acceptable use of cloud storage services for Covered Financial Information may vary based on use case.
Export Controlled Materials	Consult with Data Steward	Acceptable use of cloud storage services for Export Controlled Materials may vary based on use case.
Federal Tax Information	Consult with Data Steward	Acceptable use of cloud storage services for Federal Tax Information may vary based on use case.
Payment Card Information	Must have approval from IT	Cloud storage services may not adequately segment data to ensure that payment card data is segmented from other types of data. Additionally, contractual provisions are normally insufficient to accommodate PCI DSS compliance. Use of cloud storage services to store Payment Card Information would also unnecessarily expand the scope of the institution's compliance obligations.  Only approved, licensed, and contracted payment gateway services may be used to conduct credit card transactions at North Idaho College.  Consult with the information technology department for more information.
Personally Identifiable Education Records (FERPA data)	Consult with Data Steward	Acceptable use of the cloud storage service for FERPA protected data may vary based on use case.
Personally Identifiable Information	Must have approval from IT	The privacy of Personally Identifiable Information (PII) is highly regulated by state and federal government. Unauthorized access to PII can introduce legal, financial and reputational risks for the institution as cause harm to those individuals whose information is inappropriately accessed. As a result, this information should not be stored using cloud storage services. Users must consult with the information technology department before storing PII in cloud storage.
Protected Health Information	Must have approval from IT	Contractual provisions are normally insufficient to accommodate HIPAA compliance. Consult with the information technology department for more information.

Reclassification

On a periodic basis, it is important to reevaluate the classification of Institutional Data to ensure the assigned classification is still appropriate based on changes to legal and contractual obligations as well as changes in the use of the data or its value to North Idaho College. This evaluation should be conducted by the appropriate Data Steward. Conducting an evaluation on an annual basis is encouraged; however, the Data Steward should determine what frequency is most appropriate based on available resources.  If a Data Steward determines that the classification of a certain data set has changed, an analysis of security controls should be performed to determine whether existing controls

Calculating Data Classification

The goal of information security is to protect the confidentiality, integrity and availability of Institutional Data. Data classification reflects the level of impact to North Idaho College if confidentiality, integrity or availability is compromised.

Unfortunately, there is no perfect quantitative system for calculating the classification of a particular data element. In some situations, the appropriate classification may be more obvious, such as when federal laws require the College to protect certain types of data (e.g. personally identifiable information). If the appropriate classification is not inherently obvious, consider each security objective using the following table as a guide.  It is an excerpt from Federal Information Processing Standards (“FIPS”) publication 199 published by the National Institute of Standards and Technology, which discusses the categorization of information and information systems.

As the total potential impact to North Idaho College increases from Low to High, the classification of data should become more restrictive moving from Public to Confidential/Restricted. If an appropriate classification is still unclear after considering these points, contact the Data Stewardship review board which is composed of the Registrar, CIO, Information Technology members, Institutional Effectiveness, and Title IX coordinator.

Security Controls

 

This guideline defines eight control areas as well as the use of cloud storage for the storage, protection, and transmission of institutional data.  The eight control areas are as follows:

 

Identifier	Control Area
AS	Application Security
DR	Disaster Recovery
EA	Electronic Access Control
EN	Encryption
IS	Information System Security
ME	Media Sanitization and Disposal
NS	Network Security
PS	Physical Security

Within each control area is a collection of security controls.  Each security control is assigned a unique identifier consisting of two letters and a number.  The letters represent the control area, as denoted above in the table, and the number simply provides uniqueness. Each security control is then assigned three control ratings, one for each classification of data, illustrating whether the control is appropriate.  These control ratings are defined as follows.

Control Rating	Definition
Optional	The security control is optional for the designated classification of data. This does not imply that the control should not be implemented. Business units that would like to go above and beyond baseline requirements are encouraged to evaluate all controls for appropriateness.
Recommended	The security control is recommended for the designated classification of data but is not required due to limitations in available technology or because the control could potentially place an undue burden on a business unit to implement. Business units should document their justification for not implementing a ‘Recommended’ security control and whether or not a compensating control has been implemented.
Required	The security control is required for the designated classification of data. In situations where a ‘Required’ security control cannot be implemented, the Procedure for Exception Handling should be followed. This process allows for a more formalized tracking and approval of security risks across the College.

This guideline reflects a common set of controls that are appropriate across the entire College. It is important to note that additional or more specific security controls may be required based on individual business requirements (e.g. contractual and/or regulatory obligations). Many Industry business practices and regulatory requirements have been considered in the development of this procedure; however, it may not be comprehensive in certain situations. Business units should consider mapping contractual and/or regulatory obligations to this procedure to ensure there are no gaps in their own controls.

Application Security

The following tables define baseline application security controls for protecting institutional data, including secure development, vulnerability management and auditing. Security controls defined throughout the other portions of this document also play an important role in application security and should be reviewed prior to designing or implementing a new application.  Special attention should be paid to the Electronic Access Control section and the Encryption and Key Management section.

In addition to the following controls, consideration should be given to the security impact of an application’s architectural design.  For example, the separation of application components (e.g. frontend, application service, database service, etc.) onto separate hosts can help reduce the risk of a compromise to one of the individual components.  Similarly, placement of these components into network segments with appropriate degrees of security can also help protect the application as a whole.  For example, it might be appropriate to place an application’s database server on a more restrictive network segment than the application’s frontend service.  The type of institutional data involved and available resources will both play an important role in making architecture decisions.

Application Development

ID	Control	Public	sensitve	Restricted
AS-1	Application development includes reviews for security vulnerabilities throughout the development lifecycle	Recommended	Recommended	Required
AS-2	Application change control procedures are documented and followed	Recommended	Recommended	Required
AS-3	Controls are in place to protect the integrity of application code	Recommended	Recommended	Required
AS-4	Application validates and restricts input, allowing only those data types that are known to be correct	Required	Required	Required
AS-5	Application executes proper error handling so that error messages do not reveal potentially harmful information to unauthorized users (e.g. detailed system information, database structures, etc.)	Required	Required	Required
AS-6	Default and/or vendor supplied credentials are changed or disabled prior to implementation in a staging or production environment	Required	Required	Required
AS-7	Functionality that allows the bypass of security controls is removed or disabled prior to implementation in a staging or production environment	Required	Required	Required

Session Management

ID	Control	Public	sensitve	Restricted
AS-8	Application sessions are uniquely associated with an individual or system	Recommended for READ access; Required for all other access	Required	Required
AS-9	Session identifiers are generated in a manner that makes them difficult to guess	Required	Required	Required
AS-10	Session identifiers are regenerated a change in the access profile of a user or system	Required	Required	Required
AS-11	Active sessions timeout after a period of inactivity	Recommended	Required	Required

Vulnerability Management

ID	Control	Public	sensitve	Restricted
AS-12	Applications are periodically tested for security vulnerabilities (e.g. vulnerability scanning, penetration testing, etc.)	Recommended	Recommended	Required
AS-13	Application security patches are deployed in a timely manner	Required	Required	Required

Application Logging

ID	Control	Public	sensitve	Restricted
AS-14	Successful attempts to access an application are logged	Required for privileged access; Recommended for all other access	Required for privileged access; Recommended for all other access	Required
AS-15	Failed attempts to access an application are logged	Required for privileged access; Recommended for all other access	Required for privileged access; Recommended for all other access	Required
AS-16	Attempts to execute an administrative command are logged *	Recommended	Recommended	Recommended
AS-17	Changes in access to an application are logged (e.g. adding, modifying or revoking access)	Required	Required	Required
AS-18	Application logs are reviewed on a periodic basis for security events	Recommended	Recommended	Required
AS-19	Application logs are protected against tampering	Required	Required	Required

Supplemental Guidance

AS-05:  Input validation plays an important part in application security.  For example, if a data entry field is asking for a phone number, the application should validate that the value entered matches a format similar to (###) ###-####.  If a data entry field is asking for a date, the application should validate that the value entered matches a format similar to MM/DD/YYYY.  If an application does not have controls in place to validate input, a malicious user may be able to enter data that results in unintended consequences, such as application failure or unauthorized access to potentially sensitive data.  

AS-12:  Not only should a session identifier (SID) be unique to an individual or system but it should also be unique to an individual's or system's access profile.  For example, a user has a certain access profile prior to authenticating.  This access profile may consist of limited functionality and access to a very limited subset of data.  Once authenticated, a user may have access to increased functionality and a larger data set.  A new SID should be generated and associated with this authenticated access.  Similarly, a user may be able to enter a secondary set of credentials in order to gain access to administrative functionality.  A new SID should be generated and associated with this administrative access.  If a user has both a user session and an administrative session active, that user would have two different SIDs associated with two different sets of actions.

AS-16:  Administrative commands are those commands that typically require some level of privileged access to execute.  For example, adding and deleting users of an application, resetting a user's password and modifying how an application is configured are all examples of administrative commands that should be logged. Execution of administrative commands may occur through some type of command-line interface or they may occur through access to a graphical user interface.  The full scope of administrative commands that should be logged may vary from application to application depending on the application’s inherent functionality, the platform(s) it runs on top of or interacts with.

Disaster Recovery

The following tables define baseline controls for protecting the availability of Institutional Data and ensuring the continuity of business operations during an unplanned event. The extent to which business continuity and disaster planning controls are implemented should be based on an analysis of the business impact should a particular data set become unavailable.  Available human and financial resources will also go into the decision making process. If there is little or no impact to the College should a particular data set become unavailable, the backup and recovery strategy may be to accept the risk of not having backups.  The appropriate Data Steward should be involved in any decision to not backup Institutional Data.  If such a strategy is approved, some of the controls below may not be applicable.  It is also important to note that backup copies of institutional data should retain the same classification as their production copy.

Disaster Recovery Planning

ID	Control	Public	sensitve	Restricted
DR-1	A disaster recovery plan is documented	Recommended	Recommended	Required
DR-2	Disaster recovery plans are periodically tested	Recommended	Recommended	Required

Backup and Recovery Controls

ID	Control	Public	sensitve	Restricted
DR-3	A backup and recovery strategy for Institutional Data is documented	Required	Required	Required
DR-4	Backup and recovery procedures are documented and followed	Required	Required	Required
DR-5	Backup and recovery procedures are periodically tested	Recommended	Recommended	Recommended
DR-6	Backup copies of data are accurately inventoried	Required	Required	Required
DR-7	Content and physical location of removable backup media is tracked	Required	Required	Required
DR-8	Removable backup media is periodically validated	Recommended	Recommended	Recommended
DR-9	Backup copies of data are stored in a secondary location that is not in close proximity to the primary location	Recommended	Recommended	Recommended

Electronic Access Controls

The following tables define baseline security controls for authentication, authorization and auditing of electronic access to Institutional Data and/or Information Systems that store, process or transmit Institutional Data. Controls in this section apply to user access as well as system and/or service access.

Authentication

ID	Control	Public	sensitve	Restricted
EA-1	Electronic access to Institutional Data and/or Information Systems is uniquely associated with an individual or system	Optional for READ access to data. Required for all other access.	Required	Required
EA-2	Electronic access to Institutional Data and/or Information Systems is authenticated	Optional for READ access to data. Required for all other access.	Required	Required
EA-3	Electronic access to Institutional Data and/or Information Systems is authenticated using multi- factor authentication	Optional	Recommended	Recommended
EA-4	Electronic access to Institutional Data and/or Information Systems that traverses the Internet is authenticated using multi-factor authentication	Optional for READ access to data. Recommended for all other access.	Recommended	Required
EA-5	Electronic access to Institutional Data and/or Information Systems is re-authenticated after a period of inactivity	Optional for READ access to data. Recommended for all other access.	Recommended	Required
EA-6	Where username and password authentication is employed, passwords are managed according to the Guideline for Password Management	Recommended	Recommended	Required

Authorization

ID	Control	Public	sensitve	Restricted
EA-7	Electronic access to Institutional Data and/or Information Systems is authorized by a Data Steward or a delegate prior to provisioning	Optional for READ access. Required for all other access.	Required	Required
EA-8	Electronic access to Institutional Data and/or Information Systems is authorized based on a business need	Optional for READ access. Recommended for all other access.	Recommended	Required
EA-9	Electronic access to Institutional Data and/or Information Systems is based on the principle of least privilege	Optional for READ access. Recommended for all other access.	Recommended	Required
EA-10	Electronic access to Institutional Data is reviewed and reauthorized by a Data Steward or a delegate on a periodic basis	Optional for READ access. Recommended for all other access.	Recommended	Required
EA-11	Electronic access is promptly revoked when it is no longer necessary to perform authorized job responsibilities	Optional for READ access. Required for all other access.	Required	Required

Access Logging

ID	Control	Public	sensitve	Restricted
EA-12	Successful attempts to access Institutional Data in electronic form are logged*	Optional for READ access. Recommended for all other access.	Optional for READ access. Recommended for all other access.	Optional for READ access. Recommended for all other access.
EA-13	Failed attempts to access Institutional Data in electronic form are logged *	Optional for READ access. Recommended for all other access.	Optional for READ access. Recommended for all other access.	Required
EA-14	Changes in access to Institutional Data in electronic form are logged *	Required	Required	Required
EA-15	Electronic access logs are reviewed on a periodic basis for security events *	Recommended	Recommended	Required
EA-16	Electronic access logs are protected against tampering *	Required	Required	Required

Supplemental Guidance

EA-12 thru EA-16:  Auditing access to Institutional Data occurs at various levels.  As a result, similar requirements exist in the Application Security and the Information Systems Security sections.  In some situations, the same set of controls may fulfill all three sets of requirements.  For example, EA-12 is similar to AS-14 and IS-16. While all three deal with logging of successful access attempts, each deals with a unique type of access.  The Electronic Access Controls section deals with direct access to Institutional Data.    It is also important to note that audit logs should be classified and protected just like any other data set.  The type of data that exists in a log will help determine the appropriate classification for that log.  For example, if a log file contains passwords, security controls should be implemented consistent with the restricted/confidential classification since the Guideline for Data Classification defines Authentication Verifiers as Restricted information.

Encryption

The following tables define baseline encryption and key management controls for protecting Institutional Data.

Encryption

ID	Control	Public	sensitve	Restricted
EN-1	Institutional Data transmitted over a network connection is encrypted	Optional	Recommended	Required
EN-2	Institutional Data stored on Electronic Media is encrypted	Optional	Recommended	Recommended
EN-3	Data stored on removable Electronic Media is encrypted	Optional	Recommended	Required
EN-4	Data stored on a mobile computing device is encrypted	Optional	Recommended	Required
EN-5	Remote administration of an Information System is performed over an encrypted network connection	Required	Required	Required

Key Management

ID	Control	Public	sensitve	Restricted
EN-6	Industry accepted algorithms are used where encryption and/or digital signing are employed	Recommended	Required	Required
EN-7	Key sizes of 128-bits or greater are used where symmetric key encryption is employed *	Recommended	Required	Required
EN-8	Key sizes of 1024-bit or greater are used where asymmetric key encryption is employed *	Recommended	Required	Required
EN-9	Keys are changed periodically where encryption is employed	Recommended	Required	Required
EN-10	Keys are revoked and/or deleted when they are no longer needed to perform a business function	Recommended	Required	Required

Supplemental Guidance

ES-7 and ES-8:  These controls establish baseline key sizes for symmetric key encryption (e.g. AES and 3DES) and asymmetric encryption (e.g. RSA and Diffie-Hellman). However industry trends illustrate a gradual movement toward larger key sizes. For example, the National Institute of Standards and Technology now requires 256-bit and 2048-bit keys for certain aspects of personal identity verification when dealing with federal information systems (see Special Publication 800-78). Data Custodians should evaluate any contractual obligations that might exist when selecting an appropriate key size.

Information System Security

The following tables define baseline security controls for protecting Information Systems that store, process or transmit Institutional Data. By definition, an Information System is any electronic system that stores, processes or transmits Institutional Data.  This may include workstations, servers, mobile devices (e.g. smart phones, PDAs, etc.) or network devices (e.g. firewalls, routers, etc.).  Controls defined in other portions of this document (e.g. Electronic Access Controls, Encryption and Key Management, etc.) also impact the security of Information Systems and should be reviewed to ensure comprehensive implementation of controls.

System Hardening

ID	Control	Public	sensitve	Restricted
IS-1	Controls are deployed to protect against unauthorized connections to services (e.g. firewalls, proxies, access control lists, etc.)	Required	Required	Required
IS-2	Controls are deployed to protect against malicious code execution (e.g. antivirus, antispyware, etc.)	Required	Required	Required
IS-3	Controls deployed to protect against malicious code execution are kept up to date (e.g. software version, signatures, etc.)	Required	Required	Required
IS-4	Host-based intrusion detection and/or prevention software is deployed and monitored	Recommended	Recommended	Recommended
IS-5	Local accounts that are not being utilized are disabled or removed	Required	Required	Required
IS-6	Default or vendor supplied credentials (e.g. username and password) are changed prior to implementation	Required	Required	Required
IS-7	Services that are not being utilized are disabled or removed	Required	Required	Required
IS-8	Applications that are not being utilized are removed	Recommended	Recommended	Recommended
IS-9	Auto-run for removable Electronic Media (e.g. CDs, DVDs, USB drives, etc.) and network drives is disabled	Required	Required	Required
IS-10	Active sessions are locked after a period of inactivity	Required	Required	Required
IS-11	Native security mechanisms are enabled to protect against buffer overflows and other memory based attacks (e.g. address space layout randomization, executable space protection, etc.)	Recommended	Recommended	Recommended

Vulnerability Management

ID	Control	Public	sensitve	Restricted
IS-12	Procedures for monitoring for new security vulnerabilities are documented and followed	Required	Required	Required
IS-13	Operating system and software security patches are deployed in a timely manner	Required	Required	Required
IS-14	Mitigating controls are deployed for known security vulnerabilities in situations where a vendor security patch is not available	Required	Required	Required
IS-15	System is periodically tested for security vulnerabilities (e.g. vulnerability scanning, penetration testing, etc.)	Recommended	Recommended	Required

System Logging

ID	Control	Public	sensitve	Restricted
IS-16	Successful attempts to access Information Systems are logged	Required	Required	Required
IS-17	Failed attempts to access Information Systems are logged	Required for privileged access. Recommended for all other access.	Required for privileged access. Recommended for all other access.	Required
IS-18	Attempts to execute an administrative command are logged *	Recommended	Recommended	Required
IS-19	Changes in access to an Information System are logged	Required	Required	Required
IS-20	Changes to critical system files (e.g. configuration files, executables, etc.) are logged	Recommended	Recommended	Required
IS-21	Process accounting is enabled, where available	Recommended	Recommended	Recommended
IS-22	System logs are reviewed on a periodic basis for security events	Recommended	Recommended	Required
IS-23	System logs are protected against tampering	Required	Required	Required

Supplemental Guidance

IS-18:  Administrative commands are those commands that typically require some level of privileged access to execute.  For example, adding and deleting users of a system, starting and stopping services and rebooting a system are all examples of administrative commands.  Execution of these commands may occur through some type of command-line interface or they may occur through access to a graphical user interface.  The full scope of administrative commands that should be logged may vary from one system to the next.  As a general rule of thumb, a command that requires the use of sudo on a UNIX or Linux platform would be considered an administrative command. On a Windows platform, a command that requires a typical user to “Run as administrator” would constitute an administrative command.

Media Sanitization and Disposal

Media sanitization is a process by which data is irreversibly removed from media or the media is permanently destroyed. The following table defines baseline controls for sanitization and disposal of media that records and/or stores Institutional Data.

ID	Control	Public	sensitve	Restricted
ME-1	Electronic Media is sanitized prior to reuse *	Recommended	Required	Required
ME-2	Electronic Media is destroyed prior to disposal *	Recommended	Required	Required
ME-3	Paper-based and/or written Media is destroyed prior to disposal *	Optional	Recommended	Required

Supplemental Guidance

ME-1: A single pass overwrite of magnetic or solid state media is recommended. While multiple overwrites can be performed, this does not provide any additional assurance that data has been irreversibly removed (see the National Institute for Standards and Technology). It is important to note that a range of factors can impact the effectiveness and completeness of an overwrite operation. For example, some software may not be able to access all data on a hard drive, such as reallocated sectors resulting from a drive fault. Reuse of electronic media outside of the organization is not recommended unless sanitization can be fully validated. If available, a firmware-based Secure Erase is recommended over a software-based overwrite. In situations where a third-party warranty or repair contract prohibits sanitization, a confidentiality and non-disclosure agreement should be put in place prior to making the electronic media available to the third-party.

ME-2: Media destruction should be performed in a manner that is consistent with techniques recommended by the National Institute of Standards and Technology. Shredding and incineration are effective destruction techniques for most types of electronic media. In situations where a third-party warranty or repair contract prohibits destruction, a confidentiality and non-disclosure agreement should be put in place prior to making the Electronic Media available to the third-party.

ME-3: Common techniques for destroying Institutional Data in written or printed form include cross shredding or incineration. In situations where cross shredding or incineration are either not feasible or impractical, use of a third-party data destruction service may be appropriate. Reasonable effort should be made to track and inventory data sent to a third-party for destruction and evidence of destruction should be retained (e.g. Certificate of Destruction). In situations where documents are destroyed in large quantities or are collected and sent to a third-party for destruction, a secure trash receptacle should be leveraged to mitigate the risk of unauthorized access during the collection period. A confidentiality and non-disclosure agreement should also be put in place prior to sending any data to a third-party.

Network Security

The following table defines baseline network security controls for NIC owned and/or operated networks that transmit Institutional Data. For the purpose of this Guideline, network devices are considered Information Systems and, as a result, appropriate Information Systems Security controls should be implemented to protect these devices.

ID	Control	Public	sensitve	Restricted
NS-1	Networks that transmit Institutional Data are segmented according to access profile *	Recommended	Recommended	Required
NS-2	Access to a network that transmits Institutional Data is authenticated	Optional	Recommended	Recommended
NS-3	Controls are in place to prevent unauthorized inbound access to a network that transmits Institutional Data (e.g. firewalls, proxies, access control lists, etc.)	Recommended	Required	Required
NS-4	Controls are in place to prevent unauthorized outbound access from a network that transmits Institutional Data (e.g. firewalls, proxies, access control lists, etc.)	Recommended	Recommended	Required
NS-5	Changes to network access controls follow a documented change procedure	Recommended	Recommended	Required
NS-6	Network access controls are reviewed on a periodic basis for appropriateness	Recommended	Recommended	Required
NS-7	Controls are in place to protect the integrity of Institutional Data transmitted over a network connection *	Optional	Recommended	Required
NS-8	Network based intrusion detection and/or prevention technology is deployed and monitored	Recommended	Recommended	Required
NS-9	Network devices are configured to protect against network-based attacks *	Recommended	Required	Required
NS-10	Successful attempts to establish a network connection are logged	Required	Required	Required
NS-11	Failed attempts to establish a network connection are logged	Required	Required	Required

Supplemental Guidance

NS-1:  Network segmentation is a complex topic and strategies will vary depending on the circumstances of a given scenario. It may be appropriate to segment a network based on access profiles. For example, a database server that requires no direct user access could be placed on a network with more restrictive access controls than a web server that requires direct user access. It may also be appropriate to segment a network based on the type of data residing on that network. For example, a collection of servers that store restricted/confidential data could be placed on a network with more restrictive controls than a collection of servers that store Public data. Available financial resources will also likely play a role in the decision making process.

NS-7:  Integrity related security controls should be implemented to protect Institutional Data from unauthorized modification during transmission over a network.  Message signing is one of the more common methods of ensuring the integrity of a data transmission.  Message signing often goes hand-in-hand with encryption controls.  For example, both the Transport Layer Security (“TLS”) protocol and the IP Security (“IPSec”) protocol offer messaging signing and encryption.

NS-9:  Network devices should be configured to protect against denial of service, eavesdropping, impersonation and other network based attacks. ARP spoofing and MAC flooding are two examples of such attacks. Network devices can be configured in a variety of ways to protect against these attacks. For example, on a Cisco network device, DHCP snooping and dynamic ARP inspection can be configured to help prevent ARP spoofing attacks and port security can be enabled to help prevent MAC flooding.

Physical Security

The following table defines baseline physical security controls for protecting Institutional Data.

Physical Access Control

ID	Control	Public	sensitve	Restricted
PS-1	Physical access to Institutional Data and/or Information Systems is authorized by an appropriate Data Steward or a delegate prior to provisioning *	Required	Required	Required
PS-2	Physical access to information systems that store, process or transmit Institutional Data is secured in a manner that prevents unauthorized access	Recommended	Recommended	Required
PS-3	Physical access to Institutional Data in written or paper form is secured in a manner that prevents unauthorized access *	Optional	Recommended	Required

Datacenter Security

ID	Control	Public	sensitve	Restricted
PS-4	Procedures for obtaining physical access to datacenter facilities are formally documented and followed	Required	Required	Required
PS-5	Physical access to datacenter facilities is logged and monitored	Required	Required	Required
PS-6	Physical access to datacenter facilities is reviewed and reauthorized by a Data Steward or delegate on a periodic basis	Required	Required	Required
PS-7	Physical access to datacenter facilities is promptly revoked when it is no longer necessary to perform authorized job responsibilities	Required	Required	Required

Supplemental Guidance

PS-1: In addition to authorizing access to users of Institutional Data and/or Information Systems, physical access of janitorial, maintenance, security and delivery/courier personnel should also be authorized by an appropriate Data Steward or delegate.

PS-3: Institutional Data in printed or written form includes, but is not limited to, hard copies of electronic documents, hand written documents or notes and writing on a whiteboard. Physical access to workspaces, printers, fax machines and trash receptacles should all be taken into consideration. Common techniques for securing physical access include storing data in a locked office or a locked filing cabinet, installing whiteboards in a manner that obscures visual inspection from outside an office or laboratory and shredding documents prior to disposal. In certain situations, it may also be appropriate to procure dedicated printers and fax machines for processing sensitive data.

Cloud Storage - General Provisions

Cloud storage and applications are valuable resources that allow NIC employees to store large amounts of information and perform collaborative tasks more effectively.  However, there are risks that must be mitigated in order to properly secure the Data that is placed into and processed in the cloud.  The purpose of this policy is to provide the framework within which North Idaho College employees will be expected to operate for storage and processing of Data in cloud environments.

All Users who utilize cloud services for storage and/or processing of College Business Information and/or Sensitive Information must utilize only NIC approved and contracted cloud services for such activities.  Anyone wishing to utilize services outside of the NIC approved solution(s) must submit a copy of the contract for such services to the Information Technology Department for review prior to purchase.  Users must also review rights and permissions requested by a Cloud Application prior to installation to ensure they do not put NIC data or systems at risk of being compromised.  If the user is unsure of the level of risk associated with the rights or permissions requested, they must contact the Information Technology Department for further guidance.  Additionally, cloud service users are required to comply with any additional requirements for the storage or processing of Information prescribed in the Data Classification Guidelines

FERPA information or other federal or state defined protected data may only be stored in or processed with cloud services for which there is a Business Agreement signed by both the College Business Office and the cloud service provider in place to accommodate the mandated requirement.

Exceptions

NIC employees who are unable to comply with this policy must file an exception.  Exceptions to this policy must be approved by the Information Technology Department in association with the President of NIC and the President’s Cabinet based on academic or business need and reviewed by the business office.  Information Technology will review exceptions annually for continued application and notify the exception holder of any concerns.

Cloud storage software guidelines:

Cloud storage provides Web access to your online file storage, file sharing, and file synchronization.  For purposes of this guidance, we will refer to all of these services as 'cloud storage' services.   Below is guidance about using cloud storage services.

The responsibility for storing North Idaho College documents and files resides with the person who stores the data.  Judgment is required about how and where NIC data will be stored.

Refer to the North Idaho College procedures at the beginning of this procedure for specific information about how to handle specific types of data.

Refer to Policy and Procedure 3.08.09 for more information regarding cloud computing and data storage.

Personal vs. Enterprise cloud storage accounts

Personal cloud storage accounts are made available to the general public by various vendors. These accounts are not sponsored by North Idaho College and do not offer the same level of security or contractual protections that are afforded to an enterprise account.  Personal accounts should never be used to store anything except data that is classified as public.

Enterprise accounts are offered by North Idaho College to its students, faculty and staff. If an enterprise account is available, then it means that NIC has entered into a contractual relationship with the vendor to offer this service to its constituents. These accounts offer additional technical and contractual safeguards in comparison to personal accounts. Enterprise accounts leverage your NIC Login ID and password for authentication.   Approved enterprise accounts may be used to store some NIC data.  Please consult with the information technology department and appropriate data steward or data custodian prior to storing information on cloud storage accounts.