Hi all- Alexandra Huft here again! I thought you might find it interesting to see “behind the scenes” of how a security vulnerability eventually becomes a security bulletin.
So, I’ll start way back at the beginning. We receive reports from many different finders on issues that may or may not be a vulnerability. The first thing that we do is work to determine that we are able to duplicate what the finder has reported. Sometimes this is very simple, other times we need to go back to the finder for additional information, but whenever possible we try and recreate what they’ve discovered with our own research. We work with the affected product teams and our own experts on the Secure Windows Initiative team (SWI) to reproduce these reports. We also try to keep the finder updated with as much information as we can provide, so that they are aware of where we are in the process. We then work on determining the severity, which is not always the easiest thing. Like you, we all have our opinions, which lead to many a heated discussion in the MSRC Situation Room where we meet several times a week. We all want the best decision for all of our customers.
Okay, so fast forward a bit….after we have determined that it is a vulnerability, we then work with the product groups to build the security update. Here is where it can get tricky. Let’s say you have two product groups that need to work together on a particular update because both products have the vulnerable component. Because each group may run different testing, the possibility for one group to be ready to ship before the other is increased. We also work with other groups on extensive testing of the update to test things like application compatibility. So, what do you do? Ship one update for one product groups’ component, but not the other? Wait? What if the issue is ‘critical’ in severity? What if we find an issue in the last stages of testing that could impact customer’s applications negatively? You would think that this would be an easy decision and before I came to the MSRC I would have sworn that this would be a no brainer. Well I was wrong! As with all of our security vulnerability reports, each security update gets looked over in depth and we find that it may not be in our customer’s best interest to provide one update before the other. If we did provide one update before the other, then that may leave the component that we do not have an update for vulnerable, making our customer more at risk because the information is now public.
There is a lot of thought that goes into the security updates, and at times it may appear that we have forgotten or are just taking our time to get them out. However, like you, what we want is what is best for our customers, to be as secure as possible. As we continue to say we always appreciate feedback. If you think you may have a great idea, please share it with us. Having been in the field, like most, I know what it is like to have to deal with security issues in “real time”.
Have a fabulous rest of the week. Thanks for all you do. I appreciate it!
~Alexandra
*This posting is provided “AS IS” with no warranties, and confers no rights.*