12. Developer Security

Career stage: We are now up to date on the career, this post is based on the work I have been doing over the last 12 months since joining the Microsoft Security team to focus on Marketing. More specifically, my role is Technical Story Design Lead in the Foundational Security team.

Last year I started the research to understand the security challenges that impact the software supply chain. Following on from several major incidents, such as the SolarWinds cyber-attack, there is an increased focus on "Shift-Left", or the ability to secure software earlier in the development lifecycle.

?

Challenge: Microsoft has been at the forefront of developer security since releasing the first version of the Secure Development Lifecycle (SDL) guide in 2003, and run their internal event Microsoft BlueHat since 2005, but what more can we do to help raise awareness of how best to improve security end to end, against the latest threats?

I started my research by reading blogs and technical articles, listening to podcasts, watching videos and meeting with subject matter experts across a range of different topics and products. The information I gathered quickly became overwhelming and very complex due to the comprehensive nature of the developer world – it is huge, diverse, and full of new acronyms and weird names :)

Get ready for a few more diagrams in this post. This journey will explain how I started with a set of complex mapping and diagrams and worked them down to the simplest form diagram possible, without losing the context of all that complexity - I'd love your feedback on the result.

Beginning with the most common frameworks, I looked for similarities in the security guidance provided by Microsoft, NIST, OWASP, OpenSSF, and Google, as some of the most prominent organizations in this space. The first diagram is an overlay of the guidance from the Microsoft SDL, and the NIST SSDF, with details in the middle of how those components are applied across some of the Microsoft solutions:

As I studied more of the individual components I found new pathways in my learning journey, and of course created new diagrams almost daily. Over 1 year of studying later and now I have a catalogue of them, a record of what I learnt, covering all kinds of developer security topics. Here is one of the most complex views I created as I discovered many different components of developer security just within the Azure ecosystem (note: this does not represent the complete solution set, just what I discovered at that time):

That’s a lot to consume, isn't it? Don't worry, it got a lot worse!

I eventually turned to the trusty spreadsheet to help me track not only all the terminology but the solutions available across the industry to help with each of the security areas. I've simplified this to make it fit in a screenshot, but you should get the idea of what it does, and the formula that I'm starting to see come together.

Giving some structure to the data led me to the realization of a simple method to display the information. From all the frameworks, presentations, online conversations, and 1:1 collaboration meetings I've held, the following diagram is the first time I mapped out my approach of Code-Build-Deploy-Run (matching the headings in the spreadsheet):

I tried a few different ways to use this method to start telling more stories, and to test how robust it was. One of those attempts was to go back to mapping the NIST SSDF. I think it turned out quite well and really helps to give an overview of the many components to consider and where to deploy them.

And again, further experimentation led to more complexity, when I'm aiming to simplify, but it certainly helped to mind-map the knowledge I was gaining (and would soon forget if I didn't put it into a diagram).

I know at this resolution it is hard to see, the intent is to show how detailed the information can get and how it all fits together. I'll zoom into just one of the bubbles to show what is inside. Each line within the bubble is part of the taxonomy that I was mapping within the spreadsheet in Image 3:

By now I have certainly established that it’s a complex mapping and not something I would expect everyone to learn and remember completely. By creating this kind of taxonomy and various views of the information, I'm discovering new ways of telling different stories when the time is right. They act as a reference library for what I have learnt so far and show me the gaps in my knowledge as I continue to learn more.

With all the complexity out of the way, it’s time to start distilling this information down. There is a great quote that applies to this method "if you can't explain it simply, you don't understand it well enough". I also like "everything should be as simple as possible, but not simpler" (both likely from Albert Einstein)

I took the design from Image 4 and worked with the talented team at www.bridge.partners, especially Emily Rae Smith and Ted Hendershot , to add in some additional elements that define the kind of disciplines needed - Creative, Automated, Operational - they provided many different designs, but this one is my favorite:

I then added a few Microsoft logos to showcase some of the breadth of solutions that could be deployed to ensure end to end security of the development lifecycle:

And then I created the next level of detail by combining some of the key topics in each of the 5 focus areas, along with common terminology that is driving change in the industry. With these three images I can start a conversation about the topic of Developer Security and see where the questions and ideas go:

As I first discussed these ideas with other experts, I soon realized that the discussions are usually broken into three different areas:

1.?????How to go from secure design to secure coding: all the frameworks in the world are no good if we can’t implement them. Developers may not be security experts, but they are willing to learn how they can help impact positive security outcomes by reducing risk from the start.

2.?????How best do we secure the CI/CD Pipeline: these often-neglected areas of security sit somewhere between the DevOps expertise and the IT standards for securing devices, identities, and networks. By communicating requirements and monitoring the controls, teams can gain visibility and prioritize the remediations – improving both velocity and security through automation.

3.?????Software either comes from an in-house team, or from a trusted provider: either way we need reliable mechanisms to ensure they are deployed to a wide range of devices and different hosting services. They also need to be well maintained with new updates and changes in security best-practices that keep ahead of attacker patterns.

This resulted in a new image to capture this need:

What do you think? Did I manage to take on one of the most complex topics in cyber security and distill it down to the essentials, whilst leaving room to navigate complex conversations between different groups of experts?

You might be an IT or Security Professional studying Developer Security, or a Professional Developer trying to understand Zero Trust. You may also be early in your career, or you know all this already! - either way, I hope this is useful to you. Please let me know your thoughts, questions, and suggestions for improvement.

?

What I Learnt: The outcome is one of the simplest series of diagrams I have created, yet it conveys so many key talking points and provides a structure for digging deeper into any conversation about end-to-end software security. I shared this with some friends at the Microsoft Build conference in May and it immediately started a fantastic conversation about the needs for security operations (SOC) for software development lifecycle!

I hope to use this approach in future communications about all developer security topics, something I am quite passionate about due to the immense impact it will have on our digital world, and I'm fortunate enough to have it as a core priority for the next year :)