Project Brief

Name

Role

Scope

Alastair Fenemore

Project Sponsor

 Robin Rice

Focus Area

Key Tasks

Notes.

Governance

• Confirm and document senior level accountability;
• Identify DSH Security Working Group (SWG);
• Draft SWG ToRs, reporting requirements and meeting schedule;

Commence meeting process.

First step in the ‘top-down’ approach to security.  Obligation is to provide evidence of strategic ownership of security and to demonstrate that appropriate reporting takes place to enable strategic security decision-making.

Initial discussions suggest there is reasonable opportunity to deliver some quick wins by simply defining a structure and operating regime.

If there are concerns around the availability of senior staff then the SWG should be formed at the project level to discharge responsibilities and simply ensure that there is a line of reporting, most likely to CISO level.

Roles and Responsibilities

• Section 5 of ISMS Scope refers;

Confirm and document all security related roles and responsibilities.

This is simply about documenting roles / responsibilities.  Key ones are defined in the ISMS scoping document, but there continues to be some discussion about funding availability for different roles.  It is important to take a strategic view and initially identify the security role requirements then to fill accordingly.  A workshop with key stakeholders is recommended.

Policy and Procedures

• Review all existing policy related materials;
• Identify any policy / procedures gap;
• Draft any missing documentation;
• Define a policy map confirming role of wider UoE polices and bespoke DSH documentation;
• Define change and review schedule.

To the outside observer (or auditor) there appears to be a little confusion about the interaction of wider UoE policies and standards and those that need to be drafted specifically for DSH.  All interested parties need to be brought together to determine what existing university documentation can be extended to DSH and to identify where new policy / procedures need to be drafted.

It is important to make best use of what already exists and resist the urge to draft lots of new material if possible.

Risk Assessment and Management

• Define risk management policy for DSH;
• Maintain oversight of risk treatment resulting from initial risk assessment;
• Review risk assessment as technological changes take place;
• Review and update risk assessment prior to external certification visit.

This work has already started and this focus area is simply about the continuation of that process by ensuring that all recommendations are adopted.

On-going work will be to ensure the risk assessment is regularly updated and up to date prior to the external certification assessment.

Statement of Applicability

• Draft initial SoA based upon results of the risk assessment process;
• Update SoA throughout project as risk treatment controls are adopted.

The outcome of the risk assessment process will provide a firm foundation for the production of an SoA, particularly as there is already ISO27001 control cross referencing within the risk assessment spreadsheet.

The SoA will be regularly updated throughout the project as key controls such as IDS/IPS are implemented.

Asset Management

• Review existing asset registers;
• Confirm asset management policy;
• Review asset classification arrangements;
• Determine labeling requirements;
• Recommend improvements where required.

It is important to ensure that asset registers are complete and that information assets and the protection of these properly reflects the information classification scheme in place.  So for example, if the classification policy states that all assets will be labeled, an auditor will check to ensure this is taking place.

Incident Management

• Review procedures;
• Determine policy;
• Review external stakeholder comments on existing process;
• Update process;
• Embed in operations.

It has been suggested that NHS stakeholders may have expressed some concerns re the current IM process.  This feedback will be taken account of during the review / update process.

Performance Metrics

• Confirm security objectives;
• Define SMART criteria for each objective;
• Define evaluation process and evidence requirements.

We have defined one core security objective and 8 supporting objectives.  A process will be defined to provide evidence of how security arrangements directly support these objectives.  We will use SMART (Specific, Measurable, Attainable, Realistic and Time Bond) criteria to illustrate how this works, providing clear evidence of application for the external auditor.

ISMS Review / Internal Audit

• Define ISMS review procedures;
• Confirm audit approach (e.g. external via BDO or internal);
• Develop audit schedule;
• Embed audit process in normal operations;
• Draft evidence of audit process.

This is a mandatory compliance aspect, which requires the definition of a process to be applied and confirmation of the evidential aretefacts that need to come out of this.

It is important to confirm who will undertake the audit as this can be done internally or as an extension of the audit contract in place with BDO.  Audits can be ‘one-off’ and annual in the traditional sense, but ideally procedures should be embedded in normal operations, perhaps with a different focus area being reviewed on a monthly basis.

Technical Controls

• Confirmation of required technical security controls from risk assessment;
• Liaison with technical teams in key areas such as:

• IDS/IPS;
• SIEM and Protective Monitoring;
• Malware and AV protection;
• Access Control;
• Cryptography;
• Recovery from back-up

• Documentation of ICT arrangement and definition of

This is both follow-on from the risk assessment work and an extension of work that is already on going, such as that in relation to the deployment of IDS/IPS.  In terms of what ISO27001 requires, it is not simply about the implementation of controls but a definition of what they are required to achieve that is directly traceable to inherent risk.  Controls must be demonstrated to be effective and therefore evidence is necessary, particularly in areas such as protective monitoring.