Today marks my last day of responsibility for making my products secure. I will continue to be responsible for making my feature areas secure, but I won’t be giving out the marching orders anymore.
Since I joined the company in 2005 I was responsible for the security of technologies including the first release of the Windows Communication Foundation, Windows Server AppFabric, Windows Azure AppFabric, and a few others.
The term “Security” is quite broad and can mean many things. But there are two big buckets of responsibility that you can think about: “Security as a Feature” and “Security as a Process”. Security-as-a-Feature is the act of working on features that make your product more secure. For example, using HTTPS instead of HTTP, or implementing an identify system, etc. Then there is Security-as-a-Process, which is basically following the security best practices at every milestone of the software development lifecycle. This includes things like creating threat models, running static analysis tools, fuzz testing, etc.
I currently work on the Access Control Service so clearly I will be working on Security as a feature for quite a while. However, it is security as a process for which it has been my last day.
My responsibility has been to implement the Secure Development Lifecycle (SDL) in the products I worked on. I started this because the WCF team needed it and I was a fresh college hire who could fill the role. It was a great first experience as I was quickly recognized as an expert in my division and saw a lot of demand for me as a result.
Key lessons learned (in no particular order):
- Start with threat modeling. If you don’t know how to think about making software secure, threat modeling is a good starting point.
- 3rd party penetration testing is worth the piece of mind. Hiring an external team to focus on penetration testing, despite its cost, has an incredible return. Either you verify that you have done your due diligence and no new issues are identified, or the issues that are identified will make your product that much better.
- Learn basics of crypto and federated identity. All technical people should be familiar with basics of cryptography like signing, encryption, block vs stream cyphers, etc. This is core to understanding other security related technologies. Similarly federated identity is critical for any service that wants to sell to enterprises; it’s one of the core requirements for any enterprise customer.
- Securing your services/products can be easy. Implementing security best practices doesn’t have to be expensive. Doing a little bit of work at every step of the way makes it actually pretty cheap. It becomes a good habit.
- Define and live privacy principles. This is a big one. Define a small set of principles such that everyone can easily think about customer and privacy data in terms of those principles. Everything flows from those principles, like figuring out how to triage bugs, defining data handling policies, implementing audit logs and checks and balances, etc. I am very proud of the way that AppFabric Services handle customer data.
- Verify assumptions. When teams practice security every step of the way it becomes a great habit. But in those cases you are in danger of making assumptions about interdependencies just because they become habitual and you have mutual expectations. For each functional area as a part of the threat modeling process it is a good idea to list the assumptions you make about all of your dependencies, then verify them with the people that are the authorities.
