Welcome to MSDN Blogs Sign in | Join | Help

Trust Center Part 1: Principles

Guest writer: Sam Radakovitz.  Over the next several posts, Sam Radakovitz, one of the members of the Excel Program Management team, is going to explain a new feature in Office 2007 called the “Trust Centre”.  While Sam will be discussing the Trust Centre in the context of Excel, it is a feature that has been implemented across Office (Word, Access, PowerPoint, etc.), so you can apply much of what Sam has written about there as well.  Enjoy.

Security means different things to different people and even that meaning will vary depending on the circumstances.  For the next few posts, I’d like to spend some time explaining the work we’ve done in Office 2007 to enhance and improve the experience with security.  Let’s start with a quick look at all the features we did and why.

Overview
To help understand this post as well as future posts, Let me give a quick introduction to all the new pieces.  I’ll go into greater detail on these in future posts.

Message bar – you can think of this as the replacement for the ‘macro security’ prompt you get on open of documents.  It is a modeless bar that sits under the ribbon that informs you some of the functionality in the document has been blocked.


Trust Center – a central location for all the security settings.  This is accessible from the Trust Center button on the message bar or from Excel Options on the file menu.


Trusted locations – in 2007 you can define a set of locations that where you can place documents that are considered trusted.  Any document opened from a trusted location is considered “safe” and so things like macros will run and external data connections will work without having to answer more security questions.


Data Connections – We integrated all types of external data connections into the new security model.

So why did we so radically change the user experience for security?  How did we come up with these features?  Well, we based our work on a series of principles that we adapted from what we learned about our users.

Principles
For Office 2007 we went through a process we (and maybe others) call “threat modeling” where we sit down and go through all of our features to understand the security risks associated with each. Threat modeling is composed of three high-level steps: understanding the adversary’s view, characterizing the security of the system, and determining threats.  This helps us understand the risks with our features and allows us to account for them in the design phase of the feature which gives us the opportunity to make many features secure without an overt security model, or where a security model is needed to make it much less intrusive. Additionally we saw an opportunity to dramatically simplify and improve the consistency of the trust decisions that we asked customers to make across the Office System. This led to a comprehensive rethinking of the Office Security Model in Office 2007. The overall changes were guided by a few basic principles:

  • Secure by default
  • Avoid asking questions
  • Staying productive
  • Flexibility

Secure by default. The primary principle of the security model remains untouched, to keep the customer safe from attack.

The drive behind this principle is that security is paramount. This is often a difficult choice for a team when they realize that a useful feature also has significant abuse possibilities. Rather than having the feature ‘just work’ they have to consider how to disable or change the default working of the feature to protect the customer first, with the functionality second.

Some of the work that we did that reflects on this principle:

  • Message Bar – the document you are opening opens securely, no need to answer a security decision.
  • Trusted locations – by designating a trusted location you can lower security settings for the documents you trust while still being secure by default on documents from other places.
  • Threat modeling – Each feature has been reviewed for security issues when designed allowing us to work security into the design of the feature instead of adding it on later.

Avoid asking the customer questions they may not be equipped to answer to keep them secure.

In many situations, given the complexity of the threat, the technology involved, and the poor timing of the question, customers could struggle to make an appropriate decision. This actually leads to customers suffering from “message fatigue”, where they simply ignore the prompt and just click whatever button makes it go away. The result being that not only is our security model now worthless, the customer is at risk, and they are being interrupted and frustrated as well!

The goal of this principle is twofold. First to reduce the number and frequency of questions if possible and find another way to protect the customer, and second, if you must ask a question provide the customer with all the details possible to help them make a good decision. That second point also encompasses trying to ask the question in a context that is more intuitive to the customer.

Some of the work that we did that reflects on this principle:

  • Message bar – with the ‘macro’ prompting suppressed on open, you can open the document and start to work with it without needing to make a security decision beforehand.  This also leads to less prompts overall, so when you do get a security prompt it is more meaningful.
  • Security Prompts – because we show less prompts, when we do display a security prompt it makes it more meaningful.  We also make the security prompts more distinguishable from a standard prompt and try to include more relevant information in the prompt when possible to help you make the security decision.

Keep the customer productive; don’t require an answer from the customer before they can get work done.

This principle flows from the previous one of reducing the number of questions you ask the customer as part of your security model. We want to make sure that the customer is only interrupted when such an interruption is really necessary for the customer to keep working securely.

A key driver behind this principle is the unfortunate tendency of feature owners, having accepted the need for a security model for their feature, to gravitate to a ‘get the risk accepted and the feature back working normally’ approach to integrating security into the feature. Thus they will interrupt the customer at the first opportunity, resulting in a potential flurry of prompts that appear to get in the way of getting your work done. The goal of this principle is to push the team to instead look holistically at the customer’s task and goals and verify that their feature is the most common goal and worth resolving the risk immediately.

Some of the work that we did that reflects on this principle:

  • Message bar – no prompting on load means you can load into the document and start using it securely.
  • Threat modeling – each feature has been reviewed for security issues when designed, and catching these issues early allows us to account for them in the design instead of adding ‘prompting’ security later on.

Provide more flexibility for “solutions” which are commonly used.

The final principle addresses the fact that in most cases the security model will need to be customized. While we spend a lot of time analyzing the threat and engineering a flexible and smart security model there will be cases where legitimate content that the customer needs to use will be blocked by default and trigger questions for the customer. To meet the previous three principals it’s therefore important to have a flexible set of options for the valid exceptions.

Some of the work that we did that reflects on this principle:

  • Trusted locations – the fact that you can distinguish between safe documents and unsafe documents is a huge factor in keeping your default security settings secure and not lowering them to account for your everyday work.
  • Trust Center -  Granular security options that are explicitly labeled allow for a lot of flexibility on what gets blocked and how it gets blocked.

Summary
The security features of Office 2007 are most visible by their invisibility – customers are provided with a secure environment by default, and are allowed to get on with their work with a minimum of disruption.  In the upcoming posts, I’ll dive deeper into the new features including:

  • Trust Center – one stop shop for your security options.
  • Trusted Locations – places to store documents you deem safe.
  • Message Bar – replacement for the macro security dialog.
  • Data Connections – how it fits into the new security model.
Published Monday, July 24, 2006 6:53 AM by David Gainer

Comments

# re: Trust Center Part 1: Principles

Monday, July 24, 2006 10:15 AM by James Hancock
NOW DO THE SAME THING FOR OUTLOOK AND .NET applications!

It's very simple, give the user the dreaded security warning once with a prompt like Quickbooks does to accept access from this application from now on, and then give them a screen like above for trusted macros for managing applications that they've trusted to talk to their data.

The way you're doing it now is a horrible hack that while a stop gap that worked back in 1998 should never have made it into Office 2000, little own 2007!

# re: Trust Center Part 1: Principles

Tuesday, July 25, 2006 1:22 AM by Harlan Grove
As long as Excel can be scripted via Automation, it's not going to be secure. All it takes is a VBS file using

set xl = GetObject(Class:="Excel.Application")

to cause potential havoc.

What would be more useful would be different classes of execution permission. For example, VBA functions called as user-defined functions from cell formulas. While Excel won't run Excel OM methods that modify anything inside Excel during udf execution, it happily runs VBA's disk I/O, file system and Shell statements. It'd be nice if there were a setting that prevented udfs from altering anything *outside* Excel during udf execution. Once such a feature were in place, .XLA[M] add-ins could be given a new macro security category: restricted functions only, which would be treated as always coming from a trusted location no matter where it was located when opened.

Using locations and digital signatures is bandaid stuff. Different sets of VBA statements and Excel object model methods need to be segregated into safe and suspect classes (Erase, Load, Unload, MsgBox - safe; Open, Put, Kill, GetObject - suspect). VBA code containing only safe statements and methods should be allowed to operate under security settings under which suspect statements and methods may not.

There's a lot that can be done without any statements other than Static, Dim, ReDim and Erase in udfs, and a lot more that can be done with user forms and interface code that involves no disk I/O or other OS interaction. If there were a way to mark macro-enabled Excel files so they couldn't perform disk I/O or OS calls, such files could be allowed to run in otherwise locked down Excel environments.

And just how secure are trusted locations since the usual trusted locations like %APPDATA%\Excel would be among the first locations that any self-respecting virus writer would drop tainted XLS[M] files into?

# re: Trust Center Part 1: Principles

Tuesday, July 25, 2006 4:10 AM by kmit
So what happens if I want to open a file and I don't know if it has macros or not, then want to be able to decide whether I should let the macros run? Do I have to open it with the macros disabled, discover that it has code that I do need to run then copy it to a trusted location?

# re: Trust Center Part 1: Principles

Tuesday, July 25, 2006 2:00 PM by Gareth Horton
Does the use of "Trust Centre" mean you are English or Canadian ;)

Gareth

# re: Trust Center Part 1: Principles

Wednesday, July 26, 2006 12:59 AM by Anonymous
Harlan Grove:
If someone can run a code from any language, he/she already has sufficient tools to do all awful things. Why would he/she use GetObject(Class:="Excel.Application")?

# re: Trust Center Part 1: Principles

Wednesday, July 26, 2006 6:24 AM by Sam Rad
Hey everyone.  I'm Sam.  You may remember me from such great hits as Excel Halo Spreadsheet and Excel calendar picker <g>.  I'll be replying to the Trust Centre comments while Dave is on his vacation.

James Hancock:
I'm not 100% sure on the outlook changes, but i believe there have been changes to the Trusted add-ins model for Outlook in 2007. Outlook 2007 will run installed add-ins without blocking once up-to-date AV software is running.  I'll see if i can get more information on their security changes.

kmit:
It’s opened with macro’s disabled by default, but you can revisit that decision in the Message bar and enable them there. If you feel you need to “permanently” trust these macros, then the best option is to push the author to sign them (and you trust their certificate) or in that case move the document to a trusted location.

Gareth Horton:
Canada, good guesses :-)

Harlan Grove:
Good points.. first there is an option to change the default security model behavior when the app is being driven by automation. You can use this registry value to initialize the Application.AutomationSecurity value in the Object Model. This registry value should override any programmatically assigned value.

HKCU\Software\Microsoft\Office\Common\Security\AutomationSecurity

This is a DWORD key and it can have the following values:
3  =  msoAutomationSecurityForceDisable, disable macros by default.
2  =  msoAutomationSecurityByUI use the security value that is currently set in the Trust Center UI for each of the applications.
1  =  msoAutomationSecurityLow , current default for most apps, macros in enabled.

As hinted you can also you can have your code modify the apps behavior, see http://support.microsoft.com/default.aspx?scid=kb;[LN];317405 for the matching OM to the reg settings above.

To your broader point about “bucketing” or factoring the OM into “safe” or “unsafe” groups, this is something we have explored, indeed anyone exposed to partial trust and managed code goes there regularly. It remains a live conversation, but the most immediate difficulty is the scope of the Office OMs and trying to accurately rate the safety of every part of it. Even “partial” efforts (call everything expect this known safe set unsafe) end up just adding another layer of complexity to the security model, since you need a way to manage the “unsafe” cases.

# re: Trust Center Part 1: Principles

Wednesday, July 26, 2006 10:09 AM by Harlan Grove
Anonymous,

If the goal of a particular piece of malware were subtly corrupting Excel files, specifically, XLS files, there's no practical alternative to running Excel via Automation. But your point is sound: if one can already run scripts, there's no point to using Excel to create havoc outside Excel.

# re: Trust Center Part 1: Principles

Saturday, July 29, 2006 2:09 PM by James Hancock
Solution to the security issues:

Hash the dll/exe of the module that is trying to interop. If it changes, re-ask.

Outlook 2007 still prompts if I try and use VBA and access the contact list, and there STILL is no way to say "Go away and don't come back for this application."

Translation if you don't want to use Add-ins and you're writting C# stuff it's still incredibly difficult and a pain in the but (shims) to interop with Outlook.

AND THERE IS NO GOOD REASON FOR IT. Just a bunch of people that still don't get the concept of security. (UAP under Vista anyone???)  Asking someone the same question over and over again defeats the purpose, because they will simply answer yes all of the time without reading it.

Fix the underlying problem and have an "ask once" policy and you're getting somewhere.

Oh ya, and build into the system so that us programmers can know what called a function.

So if I call something that raises an event in code, I should be able to tell that it was raised from my code. IF it was initated by a user (mouse click, key press) I should also know this. Because if the user really did do it directly, then there is no reason to ask. Otherwise there is. Really simple thing that allows code to be truely secure and not anoy people.

# Trust Centre and Office Development

Tuesday, August 01, 2006 3:30 PM by Kevin Boske - Office Development
As developers writing code for Office, we all need to be aware of security.&amp;nbsp;Let's face it, we've...

# Sam On Forms Controls

Wednesday, August 16, 2006 3:29 PM by Microsoft Excel 2007 (nee Excel 12)
Today we have another guest post from Sam Radakovitz (Sam brought you a number of posts on the Trust...

# Sam On Forms Controls

Wednesday, August 16, 2006 3:29 PM by Microsoft Excel 2007 (nee Excel 12)
Today we have another guest post from Sam Radakovitz (Sam brought you a number of posts on the Trust...

# Sam On Forms Controls

Thursday, August 17, 2006 6:17 PM by Microsoft Excel 2007 (nee Excel 12)
Today we have another guest post from Sam Radakovitz (Sam brought you a number of posts on the Trust...
New Comments to this post are disabled
 
Page view tracker