Keeping children’s data safe online
Recently we’ve launched CBBC Buzz — an app that delivers ultra-short form videos, GIFs and pictures based around the shows and topics that our under-13 audience loves. It seeks to encourage participation through creative challenges, asking our audience to submit their own drawings, photos and videos. While the focus of the app is creating a fun community for children, CBBC Buzz also aims to encourage responsible online behaviour among the 8–10 year-olds we’re targeting.
This is the first CBBC app that has asked children to submit photos, videos and drawings to the BBC and have it all published, subject to it being checked by a human first. Due to the information involved (pictures and videos of children) it is rightly considered some of the most sensitive data we hold.
Jess Hitchman, the Product Owner for Buzz, has written a post on the app, its features, goals and how it sits in the BBC Children’s strategy. Today I’d like to talk to you about some of the thinking and technical steps we’ve taken to keep children’s data safe and secure.
Handling children’s data properly
Security of our audience data starts before we design or build products. All BBC staff have training on data security, protection and our role in helping to keep information safe. This training is backed by policies (documents) which all members of staff read, they help detail what we can and can’t do with data, e.g. how it should be stored, transported or discussed. This covers everything from ‘don’t put your password on a sticky-note on your monitor’, through to encryption standards for data storage and processing in the cloud. Specialist documentation is also available depending upon your profession, e.g. journalism, editorial or in my case technical architecture. While to most this is dry stuff, its an important foundation for everything we do with data.
In CBBC Buzz’s case, it comes to market at a time when GDPR (General Data Protection Regulation) comes into effect. All staff members have gone through training to help bring them up-to-date with the recent changes to the law and refresh existing training on security.
Finding the team to build the product
The Design and Engineering department at the BBC is responsible for designing and building websites, apps and connected TV services. We also on occasion get third parties to help us where this represents good value for our audience. In the case of the CBBC Buzz app we’ve used the company Chunk to help build and power the app.
Regardless of who is building the app, website or service, we ask the team a series of questions to prove their experience and understanding of data protection, security and the technical knowledge they possess in that field. The questions and suitability are reviewed by our Information Security team. We ensure that teams always have the necessary expertise with additional support from their colleagues from around the BBC.
Our Information Security team
While developing and building products we make use of the centralised team to help support our development. They are the experts in Information Security at the BBC. They establish the standards by which the rest of the BBC must adhere when building products or handling data. They help to write our training material and provide direct guidance to teams who are building or buying products.
In our case they provide specialist support to us when developing CBBC Buzz. They instructed us on the best practice we needed from third parties, what standards we should set and expect from them, as well as helping us to technically review the product.
Design and build with security in mind
The build of any software product should be done with security in mind at all times. It should never be treated as an afterthought. Personally I take the mantra “What would the impact be on children if the service were to be compromised?”. It gives me a healthy level of fear that encourages good development practice. Of course there are many other ways to express this, such as “What’s the worst that could happen?”, or “How could I take advantage of this feature?”. They all encourage you to be in the correct mindset during development.
One of the main techniques in security is to be as open as possible. While this may seem foolish, by exposing designs of systems to others it ensures systems are designed to be secure, rather then having security through secrecy. Exposing system designs allows others to scrutinise systems and so find issues and weaknesses.
There are many principals when designing with security in mind, including:
- Principle of least privilege, ensuring people and systems can only access and process data that they need to do and nothing more, with the rule being deny everything and allow the exceptions.
- Ensuring isolation between systems, such that should one system be compromised it can’t access data in another system with a different purpose.
- Securing user input. This is typically one of the most classic attack vectors in websites and software systems. It is important to ensure that a third party can’t exploit a system by sending data containing code in forms or submissions.
- Defence through depth, in which multiple angles are used to ensure security is in place for a given system.
We adopt these (and other) principles through everything we do. For example, for every ticket of work we pick up we hold a pre-development meeting in which we discuss the functionality and ways which it could go wrong. We always ensure at least two people have looked at the code being developed and is independently tested by our Quality Assurance team. Finally we conduct technical and security reviews on a periodic basis to surface new problems that a closed team may not consider.
Technical Reviews
As the BBC is a large organization, it has a wealth of expertise and tapping into that is a vital asset that can improve any product. Technical reviews are one way of leveraging those individuals and their skills.
What is a Technical Review?
Get a bunch of smart people in a room and talk them through your application, your infrastructure and how it’s built. You have to set aside your pride for this one — people may find holes and gaps you’d missed, or worse not like how you’ve done something, but it’s better issues are found before launch than exposed afterwards.
We also make use of our partners (e.g. hosting provider) to help carry out technical reviews and to ensure we’re making best use of their platforms.
Technical Reviews are a great tool for training. Inviting less experienced members of the team along to those sessions helps build their knowledge in the area. As you review a product and listen to the discussions, you learn about different technologies, previous war stories and potential solutions you may take to the next product. As we move to a world in which more personal information is stored and processed, Technical Reviews with a focus on security are vital.
Prior to launch CBBC Buzz has been seen by over 100 people, leading to changes in implementation in security, not only in the CBBC Buzz product but also other BBC products as a result of productive discussions.
“White Hat” Hackers
Given the work that has gone into building the product, the training of staff and the discussions about security during development, the internal and external technical reviews should lead to a solid product without issues. However, just because we’ve adopted good practices doesn’t mean we’re safe. We should test our hard work.
The term “White Hat hackers” tends to mean someone who hacks systems to do good. In practice, attempting to beat the security of a system should only be done with authorisation.
There are many out-of-the-box tools that can be used to determine vulnerabilities within systems and generate reports based on these. These are commonly used during development and in many cases automated into their development pipelines. Our Information Security team also conducts vulnerability scans against our infrastructure by request.
In the case of CBBC Buzz we also went a step further and sought a trusted external company to carry out tests against the app and the services that underpin it. Despite all our efforts they were able to find issues which we’ve since fixed.
Don’t stop now…
Its common for people to stop thinking about security at this point. Given everything that has been put into security and safeguarding data, it would seem silly to. Yet people move onto other projects, priorities shift and change. However any software that isn’t kept up-to-date will start to rot, with new vulnerabilities discovered and methods of circumventing systems found.
So key to any security of data is to keep thinking about it, keep checking for known vulnerabilities, keep patching systems. It’s also key to ensure new product features haven’t introduced new issues and problems.
And Finally
To recap, things you should think about when building systems that process personal data:
- Start with policies that set out your rules around security
- Ensure you or your suppliers have the right skills.
- Think about security at every stage of development
- Talk about what could go wrong openly and publicly within your organisation — seek feedback and suggestions
- Get someone you trust (and have given permission) to attack your services. And, of course, fix what you find
- Ensure security continues to be considered and reviewed after launch
- Routinely practise for failure or operational incidents.
So hopefully I’ve given you a taste of some of the technical processes we’ve been through to help secure CBBC Buzz.
