Welcome to MSDN Blogs Sign in | Join | Help

Microsoft Excel

The team blog for Microsoft Excel and Excel Services.
Trust Center Part 3: Making Sense of Security Settings

Today we have the third guest post from Sam Radakovitz, Excel Program Manager.  Sam is writing about the Trust Centre, a new feature for Office 2007.

Our goal is to have secured and reasonable default settings to allow customers get most work done while staying safe, however, from time to time there is also value in being able to easily and quickly verify that your settings remain secure. In previous versions of Office, checking one’s security settings was often a significant challenge due to the way the various Office security models for everything from Macros to Data Connections have evolved these settings were added to the Office UI as individual decisions. The result is checking your security settings can be a daunting task.

Office 2007 introduces a new user paradigm for Office trust settings, the Office Trust Center (located in the new Office Center with all other application settings).  By collecting all Trust, Privacy and Security settings in one central place we allow customers to manage their security stance quickly and easily.

The Trust Center provides further levels of detail on a broad selection of security settings. The discrete nature of the new Office settings results in some more settings than previous releases but in return gives you more control and transparency in your settings.  In the screenshot below, on the left side of the Trust Center dialog, you can see the breadth of settings managed by the Trust Center.


(Click to enlarge)

The Trust Center attempts to bring together all the relevant settings used to manage the security and privacy options of the application into a single easy to navigate structure.  Given the breadth of security models in Office 2007, the Trust Center design presented a number of challenges:

Density – having a separate dashboard for every setting in every security model would have made for a huge number of overlapping settings. To solve this problem we moved to break out settings in a couple of different types with logical groupings:

  • Shared Evidence settings;  Trusted locations, Trusted Publishers are pieces of evidence that multiple security models use
  • Security model settings/status; even though centralizing the evidence options simplifies the Trust Center a lot, there remains a set of detailed flexibility options and information for VBA, Add-ins and Active-X controls etc. that needs to be hosted
  • Privacy controls and opt-ins. Since security and privacy often go hand in hand having application relevant settings in the Trust Center makes sense.

Relevance – centralizing settings can help in the case where you know what you are looking for, but often a setting is more relevant in another context. For example, setting a password on a document is much more appropriate at file save time, when specifying the file name and other properties, rather than having to go to the central privacy settings location.  To this end we focused the Trust Center largely on application specific settings, where they apply to all documents, while leaving some document specific scenarios with their more appropriate work flow.

Customer Confusion – some of the Office security models and settings have been around for three versions, and users are comfortable with the settings and how to use them.  Any attempt to move them around will inevitably cause some degree of confusion and adjustment, and we needed to ensure that we were really making things markedly better with these changes.  Overall we felt that the lack of clarity in the existing settings – both due to their being scattered throughout the user interface and because their descriptions were typically overloaded and cryptic – made the transition well worth it.

More Notable Changes
I’d also like to take part of this post to point out another couple significant changes in Office 2007: high, medium, and low security settings have been replaced by more explicit options and the new default security setting for Office 2007 will provide notification for unsigned macros and not force disable them with no option of enabling as previous versions of Office did by default.

High/Med/Low Security? - What is ‘High’ security?  How does that compare to ‘Medium’ security?  Or ‘Very High’ security for that matter?  How will my Active-X controls react in any of those modes?  For Office 2007 we’ve tried to remove a bunch of ambiguity and part of it was cleaning up the high to low options.  Now each feature is broken out in the Trust Center and has more explicit security options.  For macros you can control the default enabled or disabled state, and if it should show a trust bar or warning.  The same is true for the other features secured by the Trust Center as well.

Default Settings - Since Office 2007 does not actually “block” the user from opening the document, and the code does not run, providing trust bar notification where macros are disabled is deemed acceptable.  From a security point of view the macros still do not run, and from a usability point of view customers have an easier time both getting their work done without an unnecessary trust decision and enabling the macros if necessary.

Conclusion
Balancing all the risks has been a challenge but in the end the Trust Center is a significant improvement for both normal and technically advanced users.  The structure allows the ability to be more verbose in describing the customer’s options and lead to better security decisions.  The transparency around things like add-ins etc. means that customers are better informed about what code other than the core Office code is running within their application.  They can therefore assess the possible security and reliability implications more effectively.

Posted: Friday, July 28, 2006 6:32 AM by David Gainer

Comments

Harlan Grove said:

With regard to removing supposed ambiguity, if Microsoft would include halfway decent documentation with Excel (like it used to back when it had competition), maybe there's be less confusion.

Just a thought.
# July 28, 2006 12:34 PM

Patrick Schmid said:

Funny thing happened to my two days ago. Someone sent me an XLSM which I opened. I tried and tried to use any of the buttons on the worksheet, but they just wouldn't work. I didn't see the trust bar so I started thinking that something must be wrong with the file and complained to the author. He sent me a new version claiming that it was fixed. Still didn't work.
I finally went into the Trust Center and looked at the macro security setting. I had "disable all macros except digitally signed ones" set from playing around with a different files a few days earlier. I would have very much liked to see the trust bar and tell me that macros aren't working due to my macro security settings!
# July 28, 2006 3:38 PM

Mike Rosenblum said:

Hey Sam,

Really nice stuff... The Trust Center seems very well organized and centralized. And an impressive job balancing protection with functionality while avoiding "message fatigue."

A lot of ideas for improvement have been suggested as well -- many excellent, some complicated. I think that a key remaining issue for VBA developers is that certificates are out of their comfort zone while "trust" is often a more informal process among coworkers. So, ideally, a developer would be able to email an .XLSM or .XLAM to other users and have them trust this file once and not be asked again -- without the use of digital signatures.

I wonder if it could be worthwhile to add a third choice to the "Trust In Office" security alert which shows up when clicking the 'Enable Content...' button within the Message Bar. Currently the choices are:

'    ( ) Leave this content disabled (recommended)
'    ( ) Enable this content

But I think that a third choice to "Always enable this content" could be a nice convenience for a user to be able to trust a workbook or add-in only once and not have to enable the content every time it is opened.

On the other hand, allowing the user to accidentally click this "third choice" might not be ideal; so I think that this might be handled by a checkbox that is initially disabled, as well as inset and below the 'Enable this content' radio button. This checkbox would become enabled only after the 'Enable this content' radio button is clicked. That is, something like this:

'    ( ) Leave this content disabled (recommended)
'    (x) Enable this content
'        [ ] Always enable this content without asking (not recommended)

I can't show the 3rd choice as grayed out in this post, but I'm thinking that it should be indented under the 'Enable this content' choice and disabled/gray until 'Enable this content' is chosen.

The trickier part would be in properly recognizing the file. I guess that the file should probably be identified by its name, full path and a hash of the file. If the file is later opened and edited (under trust) by the user, then the saved hash value would have to be updated/saved.  However, if the file were edited by some other external process (renamed, moved, overwritten, etc.) then the hash, name or file path would now be changed and would no longer be recognized as trusted -- the user would have to click 'Enable Content...' again from the Message Bar.

Just a thought here, I'm sure that you guys have kicked around ideas like this ad nauseam...
# July 29, 2006 9:56 PM

Mike Staunton said:

Why are you still calling them Macro settings since they impact on both Macros (subroutines) and VBA User-Defined Functions. Are UDFs also a security risk or are they just caught because their code is stored in module sheets that can also contain macro code - surely a better name then would be (VBA) Module (sheet) settings
# July 30, 2006 3:11 AM

Kevin Boske - Office Development said:

As developers writing code for Office, we all need to be aware of security. Let's face it, we've...
# August 1, 2006 3:30 PM

Sam Rad said:

Sam here again, here are some comments on your comments :)

Harlan Grove:
Part of the work here was a revamp of the Help topics shipping with the product, to cover ALL the aspects of the security model. This content is coming together and Beta 2 Technical Refresh should show a lot of it. We are also working on revamping the Office Resource Kit content online which also give good details on the new model, and it’s mapping to Office 2003 settings etc.

There’s lots of material and training online for the current version, here’s some examples..

http://office.microsoft.com/en-us/training/default.aspx

http://office.microsoft.com/training/training.aspx?AssetID=RC010425851033 (Office Security Basics)

http://office.microsoft.com/en-us/assistance/HA011403061033.aspx (Office 2003 Resource Kit Security Section Overview.)

http://office.microsoft.com/en-us/assistance/HA011403021033.aspx  (Office 2003 Resource Kit Security Section changes for 2003)

http://office.microsoft.com/en-us/assistance/CH011480701033.aspx (Customizing Outlook 2003 to Help Prevent Viruses)

Patrick Schmid:
Good topic. This has been a well travelled issue for us, and your last point is where the biggest challenge is. How can we ensure that a “trusted” document like this has not been tampered with (esp on shares etc.) while keeping the decision from being so fragile (read signatures) that it’s not worth it? Right now our option on this, is to move such documents to a Trusted Location and run them from there (via shortcut or directly). We also looked at options along this line to “move” documents to trusted locations when the user was notified but these were deemed too risky from a security point of view also.

An version of this issue that causes more complaints is the “why do I have to trust macros I write myself” issue. The “Digital Certificate for VBA projects” utility under  Microsoft Office  -> Microsoft Office Tools tries to address this by generating a selfsigned cert which is only trusted on your machine. Once you sign macros with that, we will automatically resign them on modification (once we find the private key on the machine) so you don’t have to trust them repeatedly. Trusted locations also work there.

We are still looking at these issues (hashing etc. remain an option) but for the future.

Mike Staunton:
:) We spend about 2 months talking about what to call things and make sure folks (esp. novice end users) could make a good security decision about the issue. Ultimately for some case and “macros” is one of them, the term here has what I call a “sufficient fear coefficient” such that folks can determine the right approach. Once we pick the term in the notification we need to keep it consistent in the settings (again so less technical folks can follow it).

(Just to hurt your head, consider that XL4 macros are covered by the same settings :) )

# August 1, 2006 3:31 PM

Microsoft Excel 2007 (nee Excel 12) said:

Eric is out for a few days, so there is going to be a temporary break in the compatibility posts (they...
# August 15, 2006 8:07 PM
New Comments to this post are disabled
Page view tracker