Five security lessons learned from Office 2010
By Neil Mcallister on Jun 04, 2010I continue to be impressed with the changes coming in Office 2010 (currently in beta). Previously, I explained how Microsoft drew on real-world usage data to craft the beta suite's updated UI. Security is another priority for the upcoming release, and while the improvements there aren't as readily apparent, for developers they're equally noteworthy.
The Office suite is complex and feature-rich, making it a ripe target for malware and other security exploits. Given its vast and diverse user base, however, for Microsoft to remove existing features in the name of security would be out of the question.
Instead, the Office 2010 product team concentrated on developing a new security strategy. It studied past vulnerabilities to learn how they were exploited and what could be done to prevent similar abuses in the future. The result was a new, multilayered security model based on five essential principles -- ones any application developer would be wise to remember:
1. Validate all user input before acting upon it
Any good programmer knows input validation is crucial. Unverified input can lead to buffer overruns, code injection attacks, and any number of other software flaws. But too often coders think only of validating form fields, text input boxes, and other UI elements. What about documents?
One way Office 2010 avoids unwanted security surprises is by prevalidating documents against a library of schemas of documents with known qualities -- good and bad. The idea is that Office will be able to recognize specific document types and engage proactive security measures before it starts to interpret their code -- for example, by disabling macros when it encounters documents that match the characteristics of known Word macro viruses.



