Note: The Cybersecurity Baseline is expected to be issued summer 2026 with an effective date at the end of December. See this webpage for more information about the rule.
This supplemental guidance was developed for IT staff and complements the Cybersecurity Baseline. These controls are all required, and as a university rule, are enforced and may be reviewed by internal audit to ensure compliance.
Administrative access on systems must be limited where possible. This includes administrative accounts on servers, as well as administrative privileges on endpoints. Examples of this limitation are things like using sudo on Linux/MacOS, Run As on Windows, and so on.
Secondary accounts with elevated privileges for administrative operations are another possibility for this requirement.
Access to files and applications must be limited to those who need them. Start with no permissions and only give accounts what they need. This includes public websites where sensitive information could potentially be published. For example, Google Drive files must be shared only with those who need them and not with the university as a whole. Also only grant the level of access needed; e.g. edit, comment, view.
When an individual account no longer requires access, that access must be removed. This must be part of the onboarding and offboarding process for individuals. For all account types, access must be reviewed regularly. That can be defined based on the sensitivity of the data, for example.
For applications or systems, maintainers must have an established process for requesting and approving access.
Service accounts must follow a similar process for granting access via least privilege, access reviews and access removal when no longer needed.
Currently, employees, along with their supervisor, who have not completed annual training by the due date will receive email reminders until the training is complete.
Enable or maintain the default application and operating system logging, and do not disable it. Logs must be sent to a centralized log server where appropriate. This includes things like multiuser systems or systems that are considered critical.
When logging, be careful not to log sensitive information unnecessarily. For example, debug logging often will contain sensitive information such as authentication details.
Individuals must all be uniquely identified. Credentials for individuals must not be shared. Processes and devices must all be uniquely identified as well. If there are any exceptions to this, they must be submitted and approved via the IT exception process.
For multifactor authentication, the preference is to use one of the authentication methods that already supports it, such as Entra ID. This simplifies integration and maintenance. Otherwise, if a multi-user application supports multifactor, it must be enabled.
For accounts using passwords, they must follow the Identity and Authentication Rule (to be published). Passwords must be strongly encrypted at rest. Do not reuse passwords/credentials with different applications.
Report suspected incidents. For more information on reporting events, see RUL 08.00.17 – Cybersecurity Incident Response Procedure.
See storage locations and the sensitivity of data that they are approved for. For secure disposal of data, see Secure Data Removal at NC State. See also: REG 01.25.12 – University Record Retention and Disposition Regulation.
Use modern cryptographic methods that have no known major weaknesses. For example, FIPS validated cryptographic modules.
For physical access, it is not always possible to prevent theft. For example, locks can be broken. However, the evidence that the device was tampered with or stolen is still helpful for remediation and any required disclosure.
Reviewing default access is an important part of this requirement. The default must be to deny access. Aside from initial access grants, access must be reviewed periodically and removed when no longer needed.
See RUL 08.00.14 - System and Software Security Patching Standard for additional guidance.
A software inventory is a valuable resource for tracking potential vulnerabilities. This can be achieved with a CMS or manually if the device isn’t able to be part of a CMS.
Consider who will be responsible for updating the systems and software. This may be a shared responsibility where IT personnel update the operating system and out of the box software, while an individual is responsible for any software they install.
Also consider non-standard devices, such as printers and network equipment, that may need software updates.
See the vulnerability monitoring control for additional guidance for detecting software that needs to be updated.
Devices need internet connectivity for anti-malware to receive updates. Consider that some devices may need special configuration if they have firewalled or otherwise limited connections
Scope: This control applies only to university-owned devices and systems.
If you have a configuration management system that is not in the approved list, you must submit it for approval. To do so, submit your request through the IT exception request form.
Scope: This control applies only to university-owned devices and systems.
The OIT-managed system of record is currently the ServiceNow Configuration Management Database (CMDB). If you have your own inventory, you may contact Central Services and Integration in OIT for more information on potential integrations between your inventory and the CMDB.
Scope: This control applies only to university-owned devices and systems.
Vulnerabilities can be resolved automatically or manually. There are two general categories of vulnerabilities: software and configuration.
For software vulnerabilities, automatic monitoring solutions such as Tenable or Crowdstrike can scan for and alert on vulnerable versions of many common types of software.
For configuration vulnerabilities, Tenable can detect some misconfigurations, but a best practice for preventing vulnerabilities is to have baseline configuration requirements.
Additionally, much of the current landscape for vulnerability monitoring depends on knowledge and awareness. Subscribe to notifications for the software that your department uses. Pay attention to cybersecurity news about new vulnerabilities.
Any exception requests for the requirements in the Cybersecurity Baseline require approval. You can submit your request through the IT exception request form.
The Cybersecurity Baseline does not meet all of the requirements contained in these regulatory frameworks but can help contribute to a compliant environment.