PAGE CONTENT
Systems you can use to process and store different types of data
In 2013, when we first published the Employee Protection of Data APL, we included tables of where data could be stored. These tables were limited and eventually became outdated. This year as we updated that APL, APL VI-C, we updated and expanded those tables to include common systems used to store and/or process data. Although we still link to the tables from the APL as Appendix C, we moved them to the IT knowledge base system so they could be more easily found and to make it easier to keep current.
This knowledge base article is entitled Permitted and Restricted Systems for Data Storage and Data Processing to store and process data. This includes more than 40 systems or types of devices that can be used to store data. Sections include: Data Storage Systems, User Controlled Systems, On-site Processing Systems, and Cloud-based Processing Systems. Here is an image of the first table, Data Types by Data Storage System:
If you are interested in how systems are evaluated, please read the article below on Applying Data Classifications.
Use of Add-ins, Add-ons, and Apps
A plethora of additional functionality can be added to suites of software by using applications such as Microsoft Add-ins or Google Add-ons. We are routinely asked what can be used from such stores of mostly free software. In order to enable the best opportunities for students, staff, and faculty, a group of IT professionals came together to provide guidance. The resultant IT Knowledge Base article: Can I use Add-ins, Add-ons, and Apps? warns that these are not supported by US:IT and identifies restrictions to NOT use with restricted or confidential data. This restriction holds for all add-ins, add-ons and apps, because each one performs different actions, and we don’t have the resources to review the underlying software.
Applying Data Classifications
The Data Classification APL (APL VI-I) published last year, provides for a 4-tier classification system. This more granular approach separates confidential data from restricted data which ultimately results in greater controls and protection around that data that is sought more by criminals and could lead to a greater loss to the institution. Achieving this protection based on data classification requires following an intertwined set of standards, practices, and procedures.
A framework of controls is set out in the Security Information Policy. The associated Standards found on the policy website enumerate 110 controls. Based on the classification of data, appropriate controls are applied. Of these controls 19 are required for all systems, 48 additional are required for systems with confidential data or higher, and 43 controls are required only for systems with restricted data. A sample of the variety is as follows:
- For all systems with data of any classification: 1.1 Limit access to authorized users
- For systems with data classification of Confidential: 1.8 Create and retain system audit logs
- For systems with data classification of Restricted: 13.16 Protect the confidentiality of information at rest (i.e. cryptography)
These controls based on classification are used to assess internal systems as well as external systems that are provided in the cloud.
For internal systems, we identify which controls apply to which systems and assess each applicable US:IT or functional department accordingly. Currently, we only assess systems that fall under regulatory or contractual compliance programs that require assessments.
For external systems, we evaluate all vendors that process, store, transmit, or access confidential or restricted data. We use a standard formula that Information Security Risk = Impact of an event x Likelihood of the event occurring. First, we examine the data types and classification along with the volume of data stored or processed. Based on the data classification and amount, we assign an impact level based on a ten-point scale.
When the potential impact is higher, we need to see that the controls are more stringent and we also need to consider our confidence level in the reporting of controls. For all systems with confidential or restricted data, we require that vendors agree to the University safeguarding standards as part of the contract, typically as Rider C. For systems with restricted data or a large volume of confidential data, we require vendors to complete an evaluation of their controls using the Higher Education Community Vendor Assessment Tool (HECVAT) produced by Educause. In some circumstances, we require an independent auditor assessment of their security controls.
Once systems pass an assessment, we can use the systems for the appropriate classification. However, because there are some variances for different compliance programs, we also make sure that the compliance needs are met before that type of data can be used. We have identified major systems in the Permitted and Restricted Systems for Data Storage and Data Processing charts identified in the article above.
If you have any questions or feedback about our processes or systems to be used, please contact the Information Security Office (infosecurity@maine.edu)
The Information Security Office has new information resources available, including a page on remote work and COVID-19 cybersecurity available from the Information Security portal.
Questions? Comments? Contact UMS Information Security at infosecurity@maine.edu.
(Content for this page was provided by John Forker, Chief Information Security Officer)