Boise State University Minimum Security Standards for Systems
Updated March 2019
These minimum standards serve as a supplement to the Boise State Information Privacy and Data Security Policy and Data Classification Standard. Boise State is committed to protecting the privacy of its students, alumni, faculty, and current and former employees, as well as protecting the confidentiality, integrity, and availability of information important to the university’s mission.
These standards apply to any endpoint or server that accesses University Resources, including, but not limited to the File and Print services, the University Network, Email Servers, etc.
You are encouraged to begin adopting these standards, prioritizing your systems by risk level. As cybersecurity is a rapidly evolving field that continuously presents us with new challenges, these standards will be revised and updated accordingly.
Adherence to the standards will increase the security of systems (servers or workstations) and help safeguard university information technology resources. These minimum standards exist in addition to all other university policies and federal and state regulations governing the protection of the university’s data. Compliance with these requirements does not imply a completely secure system. Instead, these requirements should be integrated into a comprehensive system security plan.
These standards apply to all devices, physical or virtual, connected to Boise State’s network or managed cloud services through a physical, wireless, or VPN connection where data is classified as Level One, Two, or Three (see Data Classification Standard).
All users with systems connected to the university networks and managed cloud services.
This section lists the minimum standards that should be applied and enabled in Level One, Two, and Three systems that are connected to the university networks or managed cloud services. Standards for Level One are generally required.
If products are not available from reputable commercial or reliable open source communities for a specific requirement, then the specific requirement may be waived by the Chief Information Security Officer until an appropriate solution is available. In such cases a Request For Exception shall be filed.
Custodians, Users, Managers, Information Service Providers, (as defined in Boise State Policy 8060 “Information Privacy and Data Security”) and lead researchers, are expected to use their professional judgment in managing risks to the information and systems they use and/or support. All security controls should be proportional to the confidentiality, integrity, and availability requirements of the data processed or stored by the system.
Data Classification – Level 1, 2 and 3 classifications of data can be found in the University Data Classification Standard.
Endpoint – An endpoint is defined as any laptop, desktop, mobile device, printer or other network connected device, even if personally owned that is on the University Network.
Server – A server is defined as a host that provides a network accessible service.
Minimum System Security Standards: Endpoints and Servers
Determine the risk level by reviewing the data, server, and application risk classification examples and selecting the highest applicable risk designation across all. For example, an endpoint storing Low Risk Data, but utilized to manage/configure a High Risk application is designated as High Risk. Follow the minimum system security standards in the table below to safeguard your endpoints and servers.
Endpoints and SeversEndpoints and Servers
|Standards||What to Do||L|
|Firewall||On Operating Systems that support it, enable host-based firewall in default deny mode and permit only the minimum necessary services.||X||X||X|
|Malware Protection||Install antivirus (examples such as Symantec, ClamAV or Windows Defender) and configured to automatically updated and run scheduled scans. University owned equipment should be tied back to a centralized AV system, on systems that support it, for reporting purposes. Alerts should be reviewed as they are received.||X||X||X|
|Equipment Disposal||All university owned equipment must go through proper Surplus Procedures.||X||X||X|
|Credentials and Access Control||Configure systems to prohibit anonymous access. Periodically review existing accounts and privileges. Enforce password age, length, and complexity. Require password protected screen savers, with a recommended 15 minute time for inactivity, though this will be dependent on system usage. Where applicable this should be configured through a centralized process such as GPO's. The minimization of administrative privileges on systems shall be implemented and administrative accounts on systems shall only be used when they are required. Normal login to systems should be done with a non administrative account.||X||X||X|
|Warranty||All devices should be purchased with an enterprise warranty. Critical systems should be under warranty for as long as they are in use or a plan should be implemented should they fall out of warranty and fail.||X||X||X|
|Regulated Data Security Controls||Implement PCI DSS, FISMA, or export controls as applicable.||X|
|Intrusion Detection||Use OSSEC or equivalent agent on systems that require it for compliance. Review alerts as they are received.||X|
|Centralized Logging||Forward critical logs to a remote centralized log server.||X|
Endpoint SpecificEndpoint Specific
|Standards||What to Do||L|
|Patch Management||Includes OS, Applications and firmware running on system. Software should still be supported by the vendor. WSUS, Ninite and Jamf are recommended for University systems for reporting purposes. While patches require testing before mass rollout, they should be implemented as soon as possible based on criticality. Typically within 14-30 days. If OS's or Applications are no longer supported by the vendor, an exception request needs to be submitted to the CISO.||X||X||X|
|Inventory||University owned systems should be registered into a centralized system (SnipeIT) or with your departmental inventory system.||X||X||X|
|Disk Encryption||University endpoints, that support it, should utilize full disk encryption with AES 256 or equivalent should be utilized. Some examples are FileVault2 for Mac and BitLocker for Windows. Mobile devices, such as laptops, that support it shall use a boot up PIN.||X||X||X|
|Configuration and Inventory Management||As required by University Audit - to Install SCCM/JAMF agent or equivalent to tie into University Inventory System (Snipe-IT).||X||X||X|
|Standards||What to Do||L|
|Patch Management||Includes OS, Applications and firmware running on system. Software should still be supported by the vendor. Kace and Satellite are recommended and are currently used for university systems for central ID and reporting purposes. While patches require testing before mass rollout, they should be implemented as soon as possible based on criticality. Typically within 14-30 days. If OS's or Applications are no longer supported by the vendor, an exception request needs to be submitted to the CISO.||X||X||X|
|Inventory||Register your server with departmental inventory system. Send the CISO a list of department's high risk servers.||X||X||X|
|Configuration Management||Centralized configuration management should be utilized where applicable. Examples: GPO based for windows servers; CHEF or Ansible for Linux.||X||X||X|
|Request a security review from Security Operations and implement recommendations prior to deployment.||X||X||X|
|Vulnerability Management||Security Operations or owner shall perform a monthly scan. Remediate critical and high vulnerabilities within appropriate time frame based on type of data stored on system and based on access allowed to it.||X||X||X|
|System Build Documentation||All servers should provide a list of services offered, who utilizes/access them, architecture diagram, firewall requirements, etc.||X||X||X|
|Backups||All systems with operational data will be backed up. These backups should be encrypted and need to be kept in a secure location. Periodically restore procedures should be verified.||X||X||X|
|Physical Protection||Place system hardware in a data center or controlled access environment.||X||X||X|
|Sys Admin Training||To keep up on current trends, system admins should attend at least one security training course annually.||X||X|
|Encryption||Physical Servers, that support it, should utilize full disk encryption with AES 256 or equivalent. Databases on servers that hold sensitive data should be encrypted. Virtual Machine that contain compliance data should be stored on encrypted backend storage.||X|
|Two-Factor Authentication||Once Implemented and the server is deemed in scope - Require two-factor authentication for interactive user and administrator logins.||X|
Security Review for New Security Software and Appliances
Departments evaluating the implementation of new software, applications or appliances, involving Level One data, should request a technology and security review through SARB (Software and Accessibility Review Board). Reviews can be performed quickly, while ensuring that best practices for technology and security implementations are considered.
Non-Compliance and Exceptions
There will always be needs for exceptions, in general, a submission to the CISO to determine and approve them is always available.
If any of the minimum standards contained within this document cannot be met on systems manipulating Level One or Level Two data, a Request for Exception must be initiated that includes reporting the non-compliance to the Chief Information Security Officer along with a plan for risk assessment and management. Non-compliance with these standards may result in revocation of system or network access, notification of supervisors, and reporting to the Office of Internal Audit and Institutional Compliance.
Questions about this standard should be directed to the Chief Information Security Officer:
Phone: (208) 426-5701