May 10, 2020
by Dan Abel
At Tes, secure systems are important to us. We hold precious information in our products that we need to protect.
Our products are built and managed by independent squads that we trust to take responsibility for quality and delivery. We have a Security Engineering Team to help our delivery teams get security right.
In this series, we’ll be writing about some of the work we do, enabling our engineering teams to deliver software that is secure by default and design.
The Security Engineering team does not exist to check people’s work or to instruct. We are there to engage with our teams of engineers. We bring information, useful data and tools to support engineering teams in making the right choices for their products.
We made a guide for engineers that plays a big part in this
The STAN is our online guide. It helps teams make sensible, secure delivery and code choices.
We call it the STAN, after Stan Lee, the Marvel Comics key creator. He coined the phrase: “With great power comes great responsibility”. Our great power is the freedom to deliver software to our users; our great responsibility: to take good care of our users’ data.
The guide provides materials to help our teams understand and think about the risks their products are exposed to. It also provides a structure to operate within to mitigate those risks.
The STAN’s job is to help our engineering teams to own security in their delivery; to understand security threats, solutions and how to work in a risky world. It does this so our teams can produce secure enough software that protects Tes and our users. It presents assessment methods and good defaults of what needs to be done.
We don’t want to waste people’s time; so the STAN gets straight to the point.
Our security team wants the STAN to be used. We've designed the STAN to be accessible and consumable. We want to avoid making the STAN another long document (these rarely get read or returned to).
It also needs to guide people and introduce them to thinking more about security. We want to support people new to an engineering career and people stepping up a level. The STAN uses technical but not security specific language wherever it can and offers links and videos to help learn about security.
We talked to a number of experts at Tes and looked at how we manage security in our products. We found a set of baseline risks that should always be managed.
These are our Secure by Default Directives that set up every product for security success. We expect every team should follow these directives when building software for Tes.
The STAN also contains a set of directives for higher risk areas and advice on how to navigate them in a bespoke way.
Telling people the risks they need to protect against is not enough. We need to also make it possible (and easy) for teams to solve these problems and manage these risks. We do this by making our current practices clear and available.
Novel solutions to problems often contain risks themselves. We also want to avoid teams reinventing the wheel. We like to point our engineers at pre-rolled solutions and link to existing examples.
Good defensive practices develop over time. The STAN is very clear about what a team has to defend against. We expect practices to change and the Security Engineering team welcomes discussion.
There’s diminishing value in building more than you need. We want teams to go fast when it’s safe to do so and to know to slow down and take care, when it’s important.
The STAN contributes to this by presenting an operating model that avoids rules for rules’ sake. Simple, low risk projects can ship swiftly. More complex and risky projects can be assessed and suitable security designed in.
The STAN offers a grading, based on the type of data being held and processed. When a product is assessed to be in a higher risk category, the team’s job is to bring more focus on security and apply a more complex set of directives.
A service would be graded as a higher risk service if it, for example, held data that would be damaging if lost or could be used for identity theft. This can happen at any point in a service's lifetime, as change occurs.
We know that the distribution of security experience will always be uneven across our teams. The STAN helps to level this and help everyone think about what they should be doing to manage risk.
The STAN includes sections to help engineers think about risk and suggests practices such as thread modelling and how to fall into a Pit of success.
The team that built the STAN works from the principle that we do not assume what somebody knows. We’ve talked to teams about the STAN and security, especially when things did not go right. We found out what was not always known and added that to our guide.
The STAN is actively developed in collaboration with our engineers and is improved by our team from their contributions and feedback.
The STAN is built in markdown in GitHub, where our engineers spend a lot of their time. It invites our engineers to review, feedback and contribute in the format they already know.
The STAN is delivered iteratively. We don't want to get everything perfect before shipping. We can always improve it through conversation with our engineers.
The STAN gives the engineering teams something to point to and talk about when we are looking to secure what we build. The security team utilises the trust that sits at the heart of remote agile teams rather than checking everyone’s work.
The Security Engineering team provides the STAN to help all our teams to know what good enough is. We are there to assist and advise when the STAN doesn't cover what they need.
Supporting teams to make informed decisions has meant that the small Security Engineering team can have a big impact. Creating the STAN first also enabled our security engineering team to focus on adding value in more risky areas, safe in the knowledge that the basics are there.