I mentioned in my last
During those 9 weeks, the test team sent out a report each week with the areas they have covered, and the issues they logged. They defined severities for issues they logged, 1 being "Critical" and 4 being "Low". Each issue has a description of their concern, and was assigned to the owner team. The agreement was that if they hit multiple critical issues in a component, they stop their testing and require that component to re-confirm their security work. The good news is that this didn’t happen. Not only that, we had no critical issues logged at all!! Now, obviously, this is not a full proof guarantee, but it’s another confirmation that we’ve done the right things.
Overall, they logged 13 "important" issues, 8 "moderate" issues and 9 "low" issues. Right now, the teams are analyzing the issues and forming their recommendations. But again, I’m really happy with this result. On a product the size and complexity as ours, these are really good results.
Our next step is to apply for the SWI Final Security Review signoff. This is being done through a sort of documentation tool. I will use the tool to document that he have met the requirements of
In parallel to this sign off, I’m working on publishing our release criteria for security. For the most part, it is the same as our Beta2 criteria. Since Beta2 allowed customers to "
Another effort that I’m working on separately is getting our division to establish a dedicated security team. Basically, replicating a little SWI of our own. If we had dedicated pen-testers, we could go into a rotation model and ensure coverage for the whole product. We could also have them participate in the early phases of design to provide expert advice on security. I’m getting support for this, now we just need to find the right people.
I think my next blog on this will be when we have FSR sign off. I can tell you all about how we managed the late-coming changes and what lessons we’ve learned.