The Essentials of CUI Classification in Higher Education and Best Practice Compliance with the CCP Framework
By Adam Strange, Global Marketing Director at Titus, by Fortra
In today’s climate of escalating cyber crime, CUI concerns reach way beyond the private sector into critical public sector organizations such as government and education. Instances of data breaches at organizations entrusted with personally identifiable information (PII) continue to proliferate, and it is now critical that government and Institutions of Higher Education (IHEs) work together to combat cybersecurity threats and strengthen cybersecurity infrastructure.
Historically, CUI within education didn’t have much of a profile. Higher education institutions and relevant entities, including state grant agencies, lenders, contractors, and third-party servicers, previously employed ad hoc house-specific policies, procedures, and markings to safeguard and control all information. But this confusing patchwork resulted in inconsistent marking and safeguarding of documents, which in the worst-case scenario, led to loss of sensitive student data.
As a result, for the first time this year we have seen the arrival of the Federal Student Aid’s (FSA) Campus Cybersecurity Program (CCP) framework. IHEs must now evidence the protection of all Controlled Unclassified Information (CUI) used in the administration of federal student aid programs authorized under Title IV of the Higher Education Act.
Compliance with CUI and GLBA
Like the Gramm Leach-Bliley Act (GLBA), the CCP affects any IHE that participates in a Title IV FSA Program and has been designed to primarily safeguard sensitive student data and to facilitate safe sharing between IHEs and third-party entities. It is meant to enhance data security resilience and maturity across IHEs and ensure the cybersecurity posture, maturity, and future compliance of each IHE with NIST SP 800-171 and other cybersecurity requirements.
Having commenced this May, as a matter of strict compliance, all IHEs must now show evidence they comply with the FSA’s guidelines to meet both legal and contractual obligations in the confidentiality, security, and integrity of all student PII. This includes demonstrating a comprehensive information security and classification program that ensures that all points where data travels or resides are treated as locations where CUI must be controlled.
Success in implementing this new framework effectively will depend on how your organization addresses CUI. Whilst it isn’t classified data, the data is still sensitive enough to require controls.
To achieve this there are key steps to master the principles of data classification, involving the categorization and labeling of student PII.
What exactly is CUI?
CUI covers ALL private student data that is created or possessed by, or on behalf of, an IHE. And its most critical element – the standardized labeling of CUI to ensure that appropriate protections can be implemented and consistently enforced – makes the rule actionable by those handling CUI.
CUI registry, which specifies, by category and subcategory, which marking must be applied to a particular data subject, also details critical procedures relating to the handling, safeguarding and control of the data as it moves through IHE and third party systems.
The marking/labeling is central to ensure that CUI data is handled and secured in appropriate ways, and is only accessible to users who need to work with it, with appropriate downstream security controls across all IT systems, devices and databases.
All IHES and federal student aid partners need to develop, implement, and enhance information security programs with requisite controls and monitoring that supports all aspects of the administration of Title IV federal student aid programs. These security programs must encompass all systems, databases, and processes that collect, process, and distribute information-including PII-in support of applications for and receipt of Title IV student assistance.
The 5 Steps to Effective CUI Classification
With the right tools and training, IHEs can demonstrate they have the capabilities in place to recognize and handle any type of CUI classification and labeling, and also produce evidence where necessary. This breaks down into five key steps:
Know the CUI you create, process, store and disseminate. Understand your contracting security obligations or partner organization’s security policies and what you need to do to comply with both these and the new framework. This includes understanding the types of information that needs to be marked, what language must be used and what the markings mean.
Get visibility of what CUI you are required to process, where it comes from, where it resides, where it is sent and who might have access to it. From here, establish what controls you need to apply to it.
Select a technology solution that will enable users to consistently apply the classification scheme, add critical metadata to the file and, via clear labeling, control who should have access to each type of CUI. Start with classifying ‘live’ data including emails, files and documents that are being received, created and handled right now. Then move on to labeling existing and legacy CUI that is stored and held around the organization.
Employ the tools that will control and protect CUI through its journey. The metadata label will enable higher grade controls to be applied within downstream DLP solutions, security incident and event monitoring (SIEM) tools, access control tools, and data governance tools to safeguard the data as it’s accessed, used or moved.
CUI frameworks evolve over time so use monitoring and reporting tools to track how CUI is being accessed, used and classified in your organization, whilst also keeping the background intelligence needed to evolve the approach in line with regulatory changes constantly available.
Failing to adequately protect CUI in IHEs has considerable implications. A data leak that exposes sensitive student PII or breaches a regulation could lead to significant compliance and legal penalties as well as sustained reputational damage.