In order to perform compliance reviews against your division, department or faculty and give you assurance that your information security requirements are appropriate, you should complete an annual self-assessment against the University’s baseline security requirements.
The University’s ‘baseline’ information security standard defines the minimum organisational and technical security controls needed to keep your systems and data secure from most of the information security threats that we currently face. In other words, we’re telling you what “secure” looks like so you can concentrate on what it is you need to do. To provide assurance to the University that your information security arrangements are appropriate, you are required to complete an annual self-assessment against the baseline. The Information Security Team (IST) has developed a tool you can use to perform this assessment – the “Information Security Baseline Assessment”.
Each year, the IST will collate the results of every self-assessment in order to:
- Determine the University’s current level of overall information security maturity and assess the information security hygiene of the University
- Identify areas of both risk and good practice
- Determine where assistance is most needed
- Provide prioritized recommendations to divisions, departments, faculties and the University as a whole
How to complete self-assessments
The assessment is presented as an Excel workbook which is broken down into a number of different sheets. All sections which are not hidden or locked from editing are mandatory. The point of contact for the assessment should typically be a senior member of administrative staff, such as a departmental administrator, who will be responsible for completing and returning the assessment. You will likely need assistance to complete the technical assessment and so we expect this section to be delegated to your local IT support staff.
By default, all systems within your division, department or faculty should be assumed to be in scope for assessment. However, we recognize that there will be exceptions to this and you are only expected to vouch for the security systems that are in your gift to control. For example:
- The infrastructure underlying the IT Services VPN service would not be in scope, but the use of it to provide remote access into your environment would be
- You are not expected to comment on the security of Nexus SharePoint but how you configure SharePoint sites and libraries to store departmental information would be in scope
What is most important of all is that you explicitly tell us what is and isn’t in scope. Ultimately, this is about assessing risk so we need to understand what is covered by the assessments.
The high-level assessment is intended to assess information security maturity across the whole department, faculty or division and should be completed by a senior administrator rather than IT staff. However, this section contains only 8 questions and is not expected to take more than 30-45 minutes to complete. You should assign a maturity score (from 0-5) for each question and provide supporting comments and reasoning where applicable. Although you may need input from certain departments to answer some of the questions (e.g. your IT support will need to provide information on IT Security and – potentially – on the management of mobile devices) you are not expected to provide detailed evidence. Answers should be based on what you know! It’s worth bearing in mind that we expect most maturity scores to be ‘2’ or less and that the target maturity across the University is to get all controls implemented to a consistent level. That means aiming for ‘3’ rather than ‘4’ or ‘5’ in most cases.
The technical assessment should be completed by an IT manager or equivalent, and should also be answered based on their current understanding of the IT estate. This should not be an overly onerous task – we anticipate no more than half a day’s worth of effort. Again, we’re not asking for detailed evidence for every question, but where controls are not in place it would be helpful to add comments as to the reasoning. We've included examples of what we might look for if we were carrying out an audit, labelled "Expected Testing". This is provided purely to give context for the controls and you're not expected to verify that all of those things are in place or to provide evidence.
Importantly, controls are either in place for all in-scope systems or they are not. If there is any doubt or if the control is not in place on all in scope systems, then the answer should be “no”. We recognize the limitations of this approach (no method is perfect) so that’s why it’s useful to include comments to help us assess the levels of risk. Remember – where a control is not in place it doesn’t mean there is automatically a risk - and vice versa! What we are looking for is honest answers based on what you know.
Of course, some controls will not be applicable in certain environments. In these circumstances it is really important to provide a clear explanation as to why this is the case, e.g.:
- ACC.16: Use two-factor authentication for remote administrative access established over non-University controlled network links, e.g. the Internet: N.a.
- Comments: No remote administrative access is permitted to any of our systems from outside the private network. As such, two factor authentication is never required
The IST recognises that one-size-does-not-fit-all when it comes to information security and the controls we’ve adopted are just one way of achieving a goal. As a result, if you don’t meet the requirement for a particular control but think you address the risk in another way you can request an exemption which will subsequently be authorised, or not, by the IST. An authorised exemption will then be considered to be “compliant” and will be valid for a period of 12 months. In order for an exemption request to be authorised you must provide evidence in the form of:
- A legitimate and documented business or technical constraint that prevents you implementing the control
- A brief description and assessment of the risk that needs to be addressed
- A description of the ‘compensating control’ being used to address the risk instead
Units may therefore comply with baseline requirements by implementing equivalent ‘compensating controls’. In these cases, the implementation is “Request exemption” the justification is provided under “Comments”, “Constraints” and “Mitigation”. A typical example would look like this:
- ACC.05 Use individual accounts with unique identifiers for the identification of all users, including administrators: Request Exemption
- Comments: Yes for all systems except for kiosk machines in the library which use an auto-logged on shared account
- Constraints: Library policy requires an unrestricted account to allow any visitor to browse the online catalogue even when they do not have a University login
- Mitigation: Lack of individual accounts leads to a risk of computer or internet abuse without the ability to trace the user involved. All kiosk machines are locked down with group policy to prevent the use of any program except Internet Explorer, and Internet Explorer is locked down to only permit browsing of sites in the Oxford domain
As part of the yearly assessments, the IST is tasked with reporting on compliance to divisions, departments and faculties. As a result, divisional working groups and the Joint Information Security Advisory Group, along with the IST, will have visibility over the returns. However, the results of your self-assessment will not be shared directly with other divisions, departments or faculties.