This exercise will look at access control issues for a student records system, similar to the one we may have at UC. One of the things that might be included in a system-specific information security policy for student records is sometimes referred to as access control lists or ACLs. In this exercise, we will create some of the details you might find in the ACLs for UCs student records.

This exercise significantly simplifies the real situation with a student records system and focuses on creating a conceptual model of the ACLs for the student records system. This may differ significantly from the way in which the ACL is implemented in the actual student records system.

While this exercise develops a data item view of access, the implementation of access controls within the UC student records system is process-based (query or update access is provided to various forms that are used to access and manipulate the data). This data item view can be a useful step in the implementation of a process-based access security model.

You will need to create a table (or matrix) that has the various classes of users in the rows. The IT resources of the system are noted in the columns. In this exercise, we will restrict these IT resources to various data clusters. The cells of the table are then the access that is provided to the resource for the relevant class of user.

The classes of users (one for each row) that could be used would include: students; lecturers; course convenors; admin staff; IT staff; senior management. This is a simplification in the real world, there are likely to be many variants of some of these user classes, particularly, the various administrative roles.

The IT data resources (one for each column) could include personal details of students; students current enrolment; students historical records; unreleased results for current units; course and unit details. Again, a significant simplification!

To illustrate this, the table could look like this, assuming you are providing read access for lecturers to historical records (this entry can be modified if you think this is appropriate):

	personal details	current enrolment	historical records	unreleased results current units	course and unit details
Students	?	?	?	?	?
Lecturers	?	?	R	?	?
etc

The values to be placed in individual cells are essentially the level of access to the IT resource that that group of users has. This may include: read; update; delete. You may also need to consider restricting the access based on certain values within the records, or other parameters as appropriate.

For example, if you have provided read access for lecturers to historical records, should this be the records for all students, or some subset of these students?

We will focus the class discussion on the top two rows of the table: one for students and one for normal academic staff (lecturers). The class discussion will look at these cell values and pick up on other issues that may arise in compiling such a table. We may also consider specific issues around access for IT staff and senior management.

Note at this point, we are trying to capture a desirable state for the access controls. At some later point, these access controls may need implementation and the practicalities of these mechanisms may result in some changes to the access levels actually provided by the system, supported by other mechanisms that help to limit access for legitimate purposes.