Every Security team should write down their Security Standards and Patterns

I have the privilege of working with a startup like company that has gone through a hypergrowth phase over the last 5 years. When I was hired, I was the 2nd Application Security Engineer in a 9 person Security team . We’re now a ~70 person Security org made of 7 different teams that are responsible for various aspects of securing our member’s data and the company.

In this post I plan on sharing a few things I’ve learned and observed over the last 5 years that I wish someone had told me when we were a small Security team. Most of these observations were more prominent in 2020 because of COVID-19 and the entire workforce moving to a work from home situation. The company I work for has always preferred in-person collaboration(which I really enjoy) and rarely allowed remote work. But when the pandemic hit that model really affected us as most of the tools and processes that were built was not built for employees working remotely.

While there are many aspects I’d like to share in this post I’m going to write about the need for documenting security standards, patterns and concepts. I realize that this might not be the most “fun” or “shiny” thing to write about, but I do strongly feel this is important. I also realize that a lot of this might sound like “duh” but it’s surprising how very few security teams do it right. Having your security requirements, standards and patterns written down helps in ways that’s not often spoken about or is given credit for. While it’s true that we should be building enough self service tools, libraries and automation in place that reduces the number of decisions every engineer needs to make, that does take time and does not substitute for having your standards and patterns written. I also think it’s a mindset change for the most part — When we were a 3 person Application Security team, I very much had the mindset that I rather spend my time finding and fixing vulnerabilities or building libraries than document standards or patterns, which in retrospect was setting myself and the team for failure.

Let me define what I call a Standard, Pattern and a Concept:

Standard — A list of security/engineering requirements on specific topic.
Pattern — A “how to” guide on implementing a solution based on security standards.
Concept — A high level document that explains a system/process without necessarily having to read an entire Technical Design Document (TDD).

Why should a 3 person team spend time writing these?

Learnings and observations:

So was this helpful to my organization? Definitely. Here are some statistics on how this improved our engagement and reduced friction with Engineering - Prior to having these documented, an engineering team would spend an average of two 30 minute sessions with Security on getting a design reviewed; one for consult (where they got the requirements and asked for if there were patterns of other teams solving similar issues) and one for design review (where a TDD was reviewed). By documenting the requirements and patterns, in a matter of 3 months, we’ve had ~70% of the teams who now skip the consult session for discussing the requirements or patterns. While we do still have some teams that come and ask us for requirements and suggestions to some very specific designs, the amount of total time spent on reviewing a design has come down drastically. Here’s another interesting statistic on the consistency of these reviews— because not all the security engineers had the same context, we’ve had cases in the past where we’ve had to change the requirements of a design after it was signed off. On an average we’ve had about 6 designs per quarter that needed re-review. Post launch of this portal, we’ve only had 2 cases of that happen.

I’m going to conclude by emphasizing that you don’t necessarily have to be a big company to get to documenting these down. If you’re a security team that’s trying to reduce the friction with engineering or reduce the number of reviews one needs to go through or if you’re trying to automate the boring aspects of the job (or all the above) and you don’t currently have your standards and patterns documented (or haven’t updated them in a while), do it.

A curious being! :) I enjoy doing Security stuff and fortunately make my living doing it. The contents I share here are my own and not the views of my employer.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store