Dogfooding: How Microsoft IT Information Security Dogfoods: Product Influence
Hi Steven Michalove here, I’m a principal program manager on Microsoft IT’s Information Security (InfoSec) group. For the last of couple weeks, we’ve been talking about Microsoft IT’s (MSIT) dogfooding process, known as the First & Best program. Concluding this dogfooding blog series, I would like to share with you how we help influence the development of products from an information security risk perspective. If you missed the prior blogs, read Mark Smith’s blog for an overview of the process, Don Nguyen’s blog for Phase 1 and Price Oden’s recent blog for Phase 2.
A little background on me, I am a subject matter expert that works with security features in the Windows OS. Our team mission is to deploy controls that mitigate security risks for Microsoft. In the last few years I have been working in the area of Desktop Encryption and the deployment of BitLockerTM internally within Microsoft. As part of the First & Best program, we act as early adopters and influencers of specific features like BitLockerTM. Our role stretches throughout the entire lifecycle of a product release to test, pilot, and improvements to a product while at the same time making a measureable impact on reducing risk.
Additionally, I am a deployer of new security technologies where I get an early look at Microsoft technologies. Basically we get the bits earlier than our customer and we can log bugs and feature requests directly with our internal product developers. Since we deploy and also evaluate the deployment early, we get a look at the features while there’s still an opportunity to both test the technology and provide input into the features themselves. We generally give three kinds of feedback and the focus may change depending on where in the development lifecycle the product or feature may be. Those three kinds of feedback usually are 1) Technical errors that often indicate some kind of bug or programming error, 2) Manageability issues and documentation that influence enterprise scale deployments and 3) Feature feedback and requests. Along with providing feedback to the product teams, we’ll often brainstorm and discuss options with the developers. Our feedback really depends upon the product lifecycle, specifically how early in the process we are involved. Additionally, often times we will also develop shared goals and pilot programs (both mandatory and optional) with target numbers. For example, we may say we want to install 1000 systems with a pre-Beta build and turn on a specific feature. We’ll then build the measurement instrumentation to support the shared goals and recruit users to help.
An example of MSIT’s involvement with influencing a product is the move from Vista to Windows 7 specifically around enterprise manageability and deployment ease of BitLockerTM. The Vista splitloader that’s needed for BitLockerTM is 1.5G. However, it can be hard to retrofit onto a system with existing drives. In Windows 7 not only did we shrink that to 100Mb (depending on certain options) but also, with MSIT’s input, improved the shrink API code base to help make the shrink operation itself more reliable. So while these improvements did not influence the BitLocker™ feature itself, it improved the deployment footprint of the feature.
The dogfooding process is an iterative approach. We’ve been early adopters of our own technology for quite some time. Some questions we ask ourselves are, “what will our universe will look like in three to five years; will we see new technologies and threats; if we could achieve a dream state, what would that be?” If you’re thinking about implementing a dogfooding program in your own company, here are a few things to consider. Primary on the list is management support. The total cost of ownership is much higher as you test technologies in the production environment. For example, we have more versions of operating systems deployed than most companies, even more than our TAP customers, since we get software very early in the pre-release cycle. Most companies would not consider these early versions production ready for at scale deployments. We do it differently and deploy these early versions into our production environments at scale to aid in the product development lifecycle – we take the first and best objective into our operation and make it part of our overall footprint. That is how Microsoft does IT.
Making the decision to use the production IT environment as an incubator for new technologies is a business decision. We have to both support and upgrade, as well as migrate and deploy, constantly. This can be expensive and that’s where having a strong business sponsorship is necessary. Seek specific measurable outcomes and boundaries. Agreeing on quantitative shared goals and resourcing them is a constant challenge but it needs to be a continuous process. Next, setup a mechanism to recycle the knowledge you gain. If early deployments teach you something, make sure you have the knowledge management in place to leverage this through to the production (finished, released product) systems deployments.
Eventually a “dogfood” cycle ends and things move to a full production environment. You can gain a lot of speed with your early learnings. Set yourself up for that. Lastly, be prepared to deal with outages and bugs in early versions; software is unpredictable at scale so you need to have a plan “B” prepared so you can back out or limit unintended consequences. You can almost always be sure the thing you least expect will be discovered in pre-release versions, plan ahead and be prepared for the unexpected. The upside is because Microsoft IT uses early versions the released versions are stable and predictable.
Hope you have enjoyed our dogfooding blog series. Watch my recent video, "Dogfooding: Deplyoment & Product Influence," as I discuss in more detail on our dogfooding process.
- Steven Michalove
Principal Program Manager
Microsoft Information Security