Partager via

Whidbey security push: what are we doing there?

  • Article

Last four weeks we have been working exclusively on security. This does not mean we have been completely ignoring security issues until the end of development cycle. Security is a feature and product features have to be designed properly to be secure. We did security threat modeling when we were still coding and since then we fixed most of the issues. However, it is beneficial to review the code once again after the product feature set stabilized and code churn is getting smaller and smaller. It is a good time to verify that assumtions made months ago still stand and threat models are still valid. Besides, code analysis tools as well as Whidbey C++ and C# compilers are getting better and better at finding possible weaknesses. We are also have new secure C Runtime library in Whidbey so existing code has to be modified to use secure CRT functions.

Ensure that all native code compiles with /GS flag and linked with /SafeSEH.
Running new versions of Prefast and FxCop Running test automation under Application Verifier.
Adding source code annotations that improve Prefast accuracy.
Reviewing potentially dangerouns API calls (see, for instance, Window UI API guidelines) and ensuring their use is justified and API is used correctly.
Switching to Secure C Runtime libraries.
Feeding VS components with fuzzy inputs
Holding security code reviews with peers and QA folks, looking specifically for security issues like potential buffer overruns, integer overflows, code asking for too many privileges, not checking input parameters, etc.
And more...

Code reviews have been taking most of the time. We try not to schedule more than 3 hours per person per day since tired people tend to overlook potential flaws. It is also difficult not to turn security review into a general code review. 

Hopefully we will done by Christmas. We will NOT rush security push to completion.

Comments

  • Anonymous
    December 13, 2004
    I DREAM of whidbey. So good luck :)
  • Anonymous
    December 13, 2004
    how about application side security (dangerous paths)
    e.g.
    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=dc5309ce-eafd-4863-b88b-6f17491bebb2
  • Anonymous
    December 14, 2004
    Looking at external data (such as file names or paths coming from outside) is part of security code review and threat modeling so it is getting done.

    As for the suggestion you have filed, I don't own any of the runtime code, I work only in the VS editor, so I can't really comment on it.