State of Security
Hi, my name is Ahmad Mahdi and I’m a Security Technologist on the ACE (Application Consulting & Engineering) Team. Here at Microsoft we have some unique perspectives on security that I would like to share with you and hope you will find informative and valuable. A lot of the security concerns that companies of nearly any size have are the same ones we face in MS IT everyday. Things like managing 60,000+ user’s desktops; managing huge amounts of spam (Microsoft is averaging almost 10 million emails per day, most of which is spam). What kind of problems does this lead to when it comes to security? What kinds of solutions are available? I’ll be discussing this in a few separate posts.
The ACE Security Approach
What our team’s security folks do specifically is we conduct reviews of the applications that Microsoft uses to run its business. We do this to ensure they are secure, and that they do not violate any corporate security / privacy policies and standards. How we do this right now is mostly a manual process. Over the coming days weeks some of our Senior Security Analysts will be posting here about what they actually do during the code review process and what kinds of effort and skills it requires.
Challenges
What we here at Microsoft IT have also found is that a lot has to be done to maintain a secure environment in addition to validating code. Here are some of the reasons for this:
- Not all software we use is written in house. In fact a lot of the software we use is purchased or licensed from 3rd parties
- Even if the software was custom developed for in-house use, it may have been developed by an outside vendor company
- Developers are located throughout the world, working for different business organizations with different levels of experience, different business priorities
- Microsoft operates in nearly every jurisdiction around the world, sometimes requiring different levels of scrutiny to ensure compliance with each jurisdiction’s requirements
Security by Design: The ASAP Process
As most anyone with a background in Information Systems security will tell you, building security into your project design process is perhaps slightly more onerous but definitely a more reliable and cost effective way of developing secure software. However before you can have secure software, you have to have a secure software process, a methodology or way of doing things that results in secure software. This is key for a number of reasons. First and foremost is consistency, if the process is not “baked in”, it results in too much deviation which reduces the level of assurance your program can ultimately provide. The consistency of the process also allows your application teams (there are literally hundreds of teams all around the world that develop or support various software to drive business functions) a consistent measurement of quality, and a known security quantity to work with. Another problem is just sheer volume, when you are trying to manage a portfolio of thousands of applications, a consistent & defined process is a necessity and not a luxury.
What our team fundamentally does is, we go through the source code of the various applications used at Microsoft to ensure they are free from security defects. Over the past several years we have made great strides in implementing and teaching secure coding practices in house but this does not always translate into all applications being secure because of the above two points. Another issue we run into is applications that have been running on the corporate network for potentially years without upgrade or modification. Currently the Microsoft line of business application portfolio that we manage is roughly 3000+ applications worldwide. So how Microsoft addressed this was by implementing the ASAP Process (Application Software Assurance Program)which was a process put into place to make Microsoft’s IT application secure.
The process covers all aspects of the standard development lifecycle, allowing us to ensure security is not something “bolted on” but rather built-in. A new application will be entered into our application portfolio tracking tool during phase I: Requirements/envisioning. This will allow our team to know that a release is on the horizon and so we can plan our resources effectively. During phase II: Functional Specs / Design our team conducts an architectural review with the team building the software and have them develop a Threat Model. Then during the tail end of phase III: Implementation we start the code review process and file any security issues found and report them back to the application team. The application team is then expected to fix the issues, which we will then check to ensure the fix is appropriate and implemented correctly. Once we have signed off, the application may be release to production. The process is repeated at each subsequent release, unless the release is so minor in nature that no security relevant changes are being implemented in which case we would not review the entire code again, we also have the option to run a diff of the code against the previous version we reviewed so that we can concentrate on only the newly added / revised code.
Over the coming weeks and months we’ll be discussing in more detail the various aspects and pieces of the process we use and what we’ve learned by developing and maturing the process over the last 3+ years. If you have any questions, please feel free to post a comment or use the feedback form.
Thanks for visiting!
Ahmad Mahdi
Security Technologist
Microsoft – ACE Team