The CESG Digital team is working to propose an alternative approach for making sensible security decisions that relate to OFFICIAL technology.
As part of this project we have been building a new desktop environment to support the user needs of our team and also give us the opportunity to test out the risk management approach we are developing on our own IT project. This post is the first in a short series to follow the evolution of this system and some of the important decisions we make along the way.
Our user needs
Our service design started with understanding the needs of our users, who are a small group split across two locations. These boiled down to:
- document sharing and collaboration - we need the ability to quickly work together, producing outputs, sharing information and ensuring that we manage it properly
- end user devices - we need to demonstrate that secure does not mean unusable, unpleasant or expensive
- email - we need to be able to communicate with the rest of the world
- task tracking – the ability to manage team workloads online will be key to working in an agile fashion whilst spread different locations
- ability to work offline - 3G connectivity between London and Cheltenham isn't great, and we need to be able to work whilst travelling
- instant messaging, audio and videoconferencing - being split across locations means we are going to need excellent communications tools
- customer engagement - we want to exemplify good, professional, customer relationship management in the way we interact externally
Our information
The next step, before making any technology decisions, was to think about what data or information the team might come into contact with. Based on our plans for the alpha we listed the following types of information:
Normal project work
Examples:
Most of our day to day working on the project and outputs
Our project planning materials
Normal correspondence within the team
Personal information
Examples:
Contact details for our team and others
Personally sensitive emails
Personal correspondence, depending on the content
Information which is sensitive to a public or commercial entity
Examples:
Correspondence and documentation relating to specific public sector organisations’ risks, systems or information
Commercial information and correspondence with companies
How we will protect our information
After identifying the information we expected to hold, we set out some basic guidelines for our team on how we would protect it. Our 3 different types of information needed different protections. We produced a guide on how we would aim to protect these types of information so we could reassure senior stakeholders that we are properly looking after information that needs to be well protected. Some highlights from the reassurance we provided include:
- We will comply with the law, and follow any contracts or commercial agreements
- We will use the ICO’s guidance when making decisions about how to handle personal data
- We will use the Cloud Security Principles and End User Devices Security Principles to structure our risk decisions around cloud services and devices
- We will label information in line with the Government Security Classifications guidance and train the team on how to treat different types of information
- For services that will handle our sensitive data we will look for independent assurance to give us confidence in the implementation of security controls, rather than rely on the assertions of service providers
- We will not place undue constraints on tools we use if the security impact is low
- We will be conscious of the fact we’re part of a larger organisation, so will escalate risks we feel uncomfortable managing ourselves
- We will keep our use of services in this area under review and seek to migrate if we are no longer confident that this service provides adequate protection for the data we store within it
Having established our user needs and set some ground rules for how we would protect different types of information, we were ready to start making some decisions about how to build our IT system. More posts about important choices we make will follow.
Sign up for email alerts from the CESG Digital blog.
2 comments
Comment by Simon Jones posted on
Hi,
Firstly, I'm really glad to see CESG blogging and sharing your thoughts and experiences with those of us elsewhere in the public sector. Really looking forward to hearing how your experiment goes, and what we can learn from it.
I was wondering about one of the points you make in this post. You say you will "label information in line with the Government Security Classifications guidance". My understanding was that we aren't supposed to be labelling information at OFFICIAL any more - could you clarify what the rules are on this, as there seems to be a lot of confusion around this.
Many thanks
Comment by Richard C posted on
The Classification Policy says that there is no requirement to explicitly mark routine OFFICIAL information, but the very sensitive material - that which is OFFICIAL-SENSITIVE should be conspicuously marked. We're following this advice, plus when we have information that is sensitive in some way we are also clearly describing how that should be handled. For example describing, in plain English, that a piece of information should not be shared outside of our team.
There is lots more guidance on the Cabinet Office's website here: https://www.gov.uk/government/publications/government-security-classifications
Thanks