Martin Roots, Managing Director of Expede Group Limited, charts the pathway to a zero trust security model for higher education
Every university has:
High-Value Data
- Student Records
- Staff Records
- Financial Records
- Commercial Data
- Research Data
- Know How
Mission-Critical Infrastructure
- Identity Management
- Networks
- Datacentres
- On-premise services (Applications, Databases, Systems, Storage & Platforms)
- Cloud-based services
- Endpoints
Data and infrastructure are open to attack through many vectors, and a mismanaged breach can have a grave financial, legal and/or reputational impact on the university, in addition to the very real and direct impact on affected individuals.
Protection of these assets has until very recently focused on protecting the perimeter, but as corporate service use cases blur (think of the many user types that a university has -students, staff, researchers, partners, contractors) and boundaries disappear (think hybrid working, remote teaching and learning, and the push of core services to the cloud), and although it is important to have an arsenal of controls in place supported by good operational security hygiene in line with best practice, it is no longer an all-encompassing approach.
Modern security means ensuring the right people have the right level of access, to the right resources, in the right context, and that access is assessed continuously – without adding friction for the user – a security concept known as Zero Trust.
But as every organisation will be at a different level of maturity, how do we get started, whilst maintaining our current (and perhaps ‘legacy’) cyber security capability/investment?
Developing and implementing an overarching Zero Trust security strategy needs to take into consideration security, IT and business initiatives currently ‘in flight’ and planned. It also needs to consider existing security controls, as well as operational ‘hygiene’ capability and capacity.
With finite university resources, key investment decisions should be taken as soon as possible as to where funds and resources should be invested – whether new money and/or additional resources are required or if the current investment (and resource allocation) could be ‘shifted’ to deliver a better outcome.
In an ideal world:
- Anything new should be delivered according to the new strategy, architecture, design principles and operating model;
- Anything ‘in flight’ but not implemented should be assessed and refocused, wheresoever possible, and adapted to fit the new direction of travel and;
- Anything not currently being addressed (e.g., the stable ‘legacy’) should be assessed for security vulnerabilities and exposure and remediated according to asset criticality/sensitivity/value.
As this is a journey that will take us through several levels of information security maturity over many years, the business case is often broken down into stages.
Stage 1 of the journey involves many phases:
- The development of a University Information Security Strategy, Architecture, Design Principles and Operational Model in line with the Zero Trust Maturity Model.
- The consolidation/delivery of inflight initiatives, and towards the end of the business case period,
- A full business case for the programme to support the strategy implementation over subsequent stages/years.
These phases are explained a little further below.
Phase 1: Design the target architecture and operating model according to the following Zero Trust Principles:
- Never Trust, Always Verify – secure corporate resources by eliminating persistent trust in everything: Identities, Devices, Workloads (Apps + Infrastructure), Networks & Data.
- Assume Breach – operate on the assumption that our environment has already been breached. Architect to minimise the effects of a breach with controls to prevent lateral movement and reduce damage.
- Verify Explicitly – where multiple modes of verification, both dynamic (RBAC, user & entity behaviour analytics, context) and static (passwords, biometrics, security tokens), must be produced to give access to resources.
Phase 2: Assess the current information security landscape.
To get to where we want to be, we first must assess where we are. This could potentially involve returning to basics:
- Assigning Information Asset Ownership (IAO) for each information asset category at a team/ department level (if not already assigned);
- The IAOs should then create an inventory of their data….
Click for diagram. - Map repositories, volume x sensitivity By mapping repositories onto a 2×2 matrix with sensitivity along one side against the volume of data held along the other, we get an approximation of priority level when you eventually get to define the plan to protect the highest value data…
Note: The output of this and the previous step directly feeds back into the ‘data considerations’ of the architecture/design phase (phase one) and, therefore, discovery and design work iteratively together.
Click for diagram. - Analyse the effectiveness of our current controls associated with each of the identified repositories. This can be achieved in workshops using a tool, such as the one pictured below to quickly capture the existing controls associated with the repository and assess the extent of their deployment concerning each repository…
Click for diagram.
And these controls can be further analysed to understand how effective they are currently at mitigating risks over each stage of the data lifecycle.…
Click for diagram.
Phase 3: Build the implementation roadmap and prioritise activity (the Full Business Case).
The previous phase gave us two specific ways of looking for areas of improvement. The first (the assessment of countermeasures currently deployed in respect to each repository) gives us a ‘heatmap’ of where effort could be applied according to a priority group.
And the second is from the analysis of how effective more detailed controls are at mitigating risks across the entire data lifecycle from creation through to destruction.
Using this analysis, potential options for mitigation initiatives can then be identified, assessed, grouped, sized and divided into execution ‘waves’ to produce a costed, prioritised, roadmap.
Ta-da!
STAGE 2 implementing the programme, really depends on the output of stage 1 and so it depends, but it always starts with building the target architecture and operating model as anything new needs to align with that. Moving the legacy towards that target is the tricky bit and could be the topic of another article!
If you’d like to discuss how Expede can help you to develop your information security strategy and approach, why not book a no-obligation appointment with one of our consultants today?
Please note: This is a commercial profile
