A sense of separation has sometimes existed between Security and Development, as though the two are not inherently connected. Security considerations have always fed into the way we work at Tes, but without the right connections it can be easy to end up viewing security as an impediment to speedy delivery or vice versa.
We started a Security Engineering team (‘SecEng’ if you like) to bridge this gap and ensure our engineering teams see strong security in data handling as critical, and crucially, something firmly within reach.
From a personal perspective, working in the Tes Engineering Team for three years has familiarised me with the way we ship software, but has left me with plenty to learn. I was pleased to be invited to join the SecEng team, which offered some insights into how an engineering team ensures security in delivery.
Most of the SecEng team’s work has fallen under these three areas:
- encouraging a security-conscious culture within Tes Engineering
- building tools to aid the team in this regard
- ensuring good communication between the Engineering Team and other company stakeholders who have a focus on managing risk
Building culture is often a challenge. We’ve found the wider Tes Engineering team to be receptive and helpful. It helps that the Security Engineering team’s members are all software engineers who have recently been members of product squads. As a result we have a clear understanding of the technical side of the Tes website and what makes it tick. The team can relate to the product squads and provide them with appropriate guidance.
This ‘soft’ side has offered some real learning points. I’ve enjoyed the threat-modelling sessions we’ve run for individual product teams in particular. Other guidance we’ve provided includes Tes Engineering knowledge-sharing sessions, and the ‘Secure Engineering Standard’. Our standard takes the form of a targeted internal guide laying out squads’ security obligations (which differ based on the kind of data being handled) and providing the information and resources needed to meet them. Helping to write the standard required me to research technical security concepts - the OWASP Top 10 was an excellent resource.
While preaching a positive security culture, we wanted to ensure we also gave practical help. Our engineers love to hack and automate solutions to everyday problems, and we used this approach to address team-wide issues like NPM vulnerabilities. In conjunction with a group of Tes engineers, we’ve built internal software to track the number of NPM vulnerabilities in our live applications each night, and report these levels to our team’s stakeholders. We’re working on alerting that will tell relevant squads when new vulnerabilities are discovered by NPM.
We are not the only standard bearers for security at Tes. Other groups (such as Information Governance) need to know how the Engineering Team is taking care of people’s data. We have a role in bridging the gap and have been doing so through automated reporting (such as that for NPM vulnerabilities), plenty of diagrams (using the excellent Miro), assessing the security of new integrations and illuminating raw data for the benefit of others (such as lists of the cookies used on the Tes website). In general our team needs to act as an ambassador within the Engineering Team for outside stakeholders and vice versa.
Drawing diagrams of our extensive architecture helps bring home how complex an application’s attack surface can be - it has been an eye-opening experience.
Our efforts have helped the Engineering Team to view security as part of its ordinary work, and to demonstrate this on a daily basis. We’ll continue to strive to make security understandable, accessible and deliverable. We hope that within a year we can move to a guild model where security is solved by a group across the products we build. From a personal perspective, I’ll certainly be taking my learnings and experience into the future product teams I join.