Embed security in your teams

During AWS re:Invent I attended the SEC322: Transform builder velocity with security chalk talk. I would have pointed you to the recording on YouTube. But unfortunately, chalk talks are not recorded! So instead you have to do it with my interpretation of the session.

The title of the session was Transform builder velocity with security. Most of you might recognize the feeling of being stopped by security when you want to go-live with your application. We tent to blame the security team at this point saying that they are the reason for the delay. The problem with this is that it has a huge impact on your development velocity. You are ready to deploy, but you can’t. And there is that potential risk that you need to go back to the drawing board because you made a fundamental mistake in your design.

The solution seems strait forward. Include security earlier in the process. And yes, this will work in the beginning. But when your organization starts to grow you will face scaling issues in your security team.

So, when you talk about scale you could use AWS itself as an example. They have a lot of teams and they seem to do a good job. And AWS always stated that there is a security person on each team. But I never heard how they actually do this. This all changed for me in this session.

Guardians

In this session Collin Pace and Anya Khlobystina explained that each team should have a guardian. The guardian will ask all relevant security questions to the team. So they will play the role of the security person on the team. So where is this guardian coming from? Well, from the team! In theory anyone can become a guardian.

AWS relies on the ambitions of the individuals to fulfill this role. The reason behind this is simple. When you have someone how wants to do the job from ambition they are more invested versus an appointed person. Ambition persons bring that spark that drives them, that motivates them to be the best version of them selves.

These guardians are supported by other more senior guardians. And there are training courses available to support the guardians in their journey.

The whole idea of having these guardians in the actual teams is to identify potential security issues as soon as possible. In the design phase, but also in all the steps that follow. They know the workload that they are building so they have the best insights on why and how the workload is build.

Conflicting interests

So like in any organization you might have a conflict between the security team and a product owner that wants to ship.

When working with guardians this shifts to the guardian. But a guardian can always ask the security team to confirm that the concern is legit. The only difference is that you are still in the design phase, or in the implementation phase. You are not ready for production yet, this is a big difference!

The team is not stopped, only a specific area is being discussed. So the rest of the team can still continue on making sure you are ready for a release.

Conclusion

With the use of guardians you are embedding the security role in your teams. This will allow you to act faster on potential security risks. And prevent them from being build in the first time.

The time that you save, will be used to develop your workload. And this will increase your building velocity!

Photo by cottonbro studio