You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
Today we have the second guest post from Sam Radakovitz, Excel Program Manager. Sam is writing about the Trust Centre, a new feature for Office 2007.
Prior to Office 2007 the Office security model has had solid success in helping combat things like macro viruses, but that has come at a price for legitimate macros and for customers who didn’t care about macros at all.
To even open a document you first had to “get past” a prompt something like the following:
(Click to enlarge)
As mentioned the customer needs to “answer” this question before moving on to do any work. Let’s explore this a little for a moment from the point of view of the principals outlined in the previous blog post. It’s certainly secure by default, the code is not enabled, and indeed the only option at first glance seems to be “Disable Macros”. It is, however, asking the user a question, and provides some reasonable details – the file name, the fact that the macro signed by Microsoft, etc. And after parsing the text we can figure out that by trusting the publisher we can enable the macros (and by extension the solution flexibility of not being prompted again for macros from this publisher kick in).
However the prompt fails on the principle of keeping the customer productive. In short the user is sitting in Word with no context about the file, which might give a clue to the important question of “do I l really need to enable the macros to do what I set out to do?” Worse, the user cannot progress until they make a decision, and they must make this decision every time the file is opened. Many customers, faced with this question repeatedly, set their macro security settings to Medium or even Low, exposing themselves to greater risk just to avoid the prompt.
Let’s compare this to the Office 2007 experience. Looking at the screenshot below, the document is opened immediately, and the user’s looking at the workbook. We can read the text of the document and work with it. Instead of the prompt, near the top the document there’s a notification – the ‘Trust Bar’ – indicating that macros have been disabled and allowing the customer to re-enable them if that’s desirable.
The customer no longer has a message to answer; they are sitting in the document ready to work. They can read the text and interact with the document, and the Trust Bar notification is there allowing them revisit the secure default decision if they need to run the code.
The biggest change is in productivity – the customer’s expectations are met, the document opens and they can continue with their work. Office quietly enforces a reasonable default security setting and the user has the flexibility to revisit that decision later, when as part of their more normal flow of work they may notice a document or solution isn’t working as expected. In many common cases they may never need to interact with the security issue, getting the planned work done without having to make a decision in order to just get the document open.
This experience applies to other common security situations too, including ActiveX controls, application add-ins and extensions etc. where dealing with the security notification is clearly not part of the primary task. Where data integrity requires that the user address a security issue we will still use a modal dialog to ensure the user gets the outcome they want from Office, but in the most common cases Office 12 will just stay out of the way.
The next screen shot below shows what you will see when clicking on “Enable Content” in the Trust Bar. Again the path to the relevant file is there, as is the signature evidence, but note that there’s a little more detail about the signature in the notification as well as some discrete options to just enable the macros or always trust the publisher and have the code run without being blocked in future.
One further issue that has caused confusion for Office customers in the past is that in an attempt to bolt on security after a feature or behavior has proven to include some security threat or risk, engineers have tended to overload an existing security model. A good example is again the VBA Macros case, where in the past Office has ’overloaded’ the VBA macro security model to cover items like Com+ Add-ins, Application add-ins (extensions), even things like updating document data. This, combined with the notion that some “installed” extensions and templates are automatically trusted, has made understanding “why” some document or solutions prompt and some others don’t difficult for customers to grasp.
In Office 2007 we have broken down the security models to have very discrete behavior, there are separate settings for VBA Macros, ActiveX control, Application extensions (like Com+ Add-ins etc.) and Trusted Locations for solution documents. The goal here is if the user has to make a decision it’s more transparent what that decision is about.
This clarity combined with being able to review and examine all security decisions associated with the document together in the Trust bar allows the user make a more informed and holistic decision about the trustworthiness of the document, rather than be bullied into it one prompt at a time.
Finally, it’s worth noting that while Office 2007 will greatly reduce the number of security prompts, it would be unrealistic to expect that all prompts will be removed. For technical and indeed usability reasons Office may still ask for a security decision, but this will most likely be in the context of using some feature or extension rather than simply opening a document.
Comments: (14) Collapse
The "Leave this content disabled (recommended)" seems to be detracting from your overall goals of helping the user.
You don't tell them why that's the recommended option, and it's not clear that that recommendation is independent of the digital signature on the file.
I would think that every instance of "(recommended)" through all of Windows and Office should be purged.
I'm looking at this from the point of view of an end user that writes macros used by other team members. When the macros are disabled like this, it just makes it harder to create shared custom spreadsheets.
The *concept* of a digital signature is great, but the *reality* is that it is not straightforward on how to obtain the digital signature, and I'm assuming there are related costs as well.
If you want to make the end user experience safer, you should make it easier for publishers to obtain the certificate. (Note that the current MSDN pages just has a link to the homepages of companies that offer these; it doesn't actually walk you through *getting* one).
When the user chooses to enable macros via the security alert bar will the Workbook_Open() procedure be called?
If so, it will interfere with open procedures that rely on the workbook being in an unmodified state.
If not, code in Workbook_Open will skipped.
As mentioned by Harlan (I think) earlier...This whole fuss about preventing a macro code from running seems to be an overkill... No self respecting malacious code creator bothers about writing viruses in Excel Macros...
Also If someone wants to force a user to run a Workbook_Open() procedure in an Excel file he would simply have to convert the file to an exe file (XL to Exe)and no matter what your macro security setting is.. the Workbook_Open() code will run....
Again you guys have tried to fix something that wasnt broken...
Instead MS should have spent more time on
a) Encrypting the worksheet and workbooking protection password with a 128 bit encryption...
b) Closing the Backdoors to VBA
These flaws have been there since 97....
Sam
Users may be confused to see that a macro is published by Microsoft but the publisher is not trusted. I suggest that when you cannot verify the publisher's certificate, you should use something like "Signed by someone claims to be Microsoft" instead.
Sam, you're misquoting me slightly. What I meant was that if there's any scripting language on a PC (and there's almost always VBScript on Windows PCs), there are ways to run Excel via automation. Why would anyone want to? Because it's easier to infect XLS files with Excel itself than by screwing around with XLS files directly.
Without VBA, there's not much use in user forms, there are no udfs, and there are no macros. As I see it there's a difference between preventing macros from damaging disk files and the OS on the one hand and preventing macros from making any changes in workbooks in open files. To be safe, file operations on open files and opening other files could be considered suspect operations. But there's still a lot that can be done with macros even if macros can only operate on files already open. I realize it'd be difficult to segregate VBA statements and OM method calls into safe and suspect categories, but it's not impossible. Better usually available but highly restricted macros than usually unavailable but completely unrestricted macros.
And what virus writer wouldn't go after Personal.xls? If there are 'trusted' locations, there's a HUGE security hole already. Restricting macros on a file by file or folder by folder basis is doomed to fail. Only restricting what macros would be allowed to do has any chance of offering reliable security.
Harlan, here you go www.microsoft.com/careers :)
Sam I agree with Dan's comments and hope you will have a blog on the topic.
I occasionally write excel macros that are shared with my co-workers. Although I only write them for people I know, the spreadsheets may then be shared with that person's team, and I won't know each team member. They are usually distributed via email.
So how do I easily make my spreadsheets trustable?
I do not work in the IT department, and I know any corporate solution, would be cumbersome, probably taking several weeks to get approval and with a cost implication.
Would there be some way "signing" my spreadsheet (or the macro's inside) with my outlook email address (coporate). Internally this would be probably enough to be trusted, externally it would not be trustworthy.
Harlan's comment about "file operations should be considered suspect". While I think I understand why Harlan has said that, about 50% of the macros I write are about reading data in from different sources, glueing them together to make a decent report. File operations are a very useful feature and to restrict them would be a big negative.
Please, Please, Please address the issue of _Open event handlers in Office. We have VBA applications that end-users must not open with macros disabled. It is bad enough that they are able to do this, it will be a disater if it happens by default.
So what happens in this scenario?: Everything that crosses a user's desk gets thrown into My Documents by default. This is naturally the first location a user designates as trusted.
The protection is not just transparent, it is nonexistent.
Olala - "Users may be confused to see that a macro is published by Microsoft but the publisher is not trusted."
Too true! Far too many people assume Microsoft is a trustworthy publisher. Just because it is not, presumably, a deliberate purveyor of malware does not mean everything it pushes down the pipe is desirable for everyone.
Biff, who wants to work when they can gripe?
I'm responding to "A User"'s post about the workbook open macros. Here's a method I've used in Excel 2003:
Save your spreadsheet so it only has a title worksheet visible that tells users they have to open it with macros enabled. Make the other sheets xlVeryHidden.
If the user opens it without macros enabled he will just see your message.
If he opens with macros enabled you can have the workbook open macro unhide the necessary sheets.
Would this method still work with the new trust centre, or will it ask the user if they want to trust the macros *each* time they open it?
"A User" : -"We have VBA applications that end-users must not open with macros disabled. It is bad enough that they are able to do this, it will be a disater if it happens by default. "
As I mentioned earlier its pretty simple to ensure that the user cannot disable the macros no matter what the security setting...
Just use XL 2 EXE (check out Orlando Site)
and convert the xls file to an Exe file....
I'm back again, thanks for all the feedback and comments, it is taking me a bit to address them, so also thanks for your patience.
Greg Hingsbergen:
It’s the secure default behavior out of the box, so in that sense it’s recommended, both in terms of helping you “remember” if you changed the setting and/or if you don’t feel confident in the decision. We have done a lot of work to help users understand the decision, but there will still be those who don’t take the time to review the info, or got to the dialog by accident and just want to get back out safely.
Dan:
PKI provisioning and infrastructure is a challenging, and while Microsoft’s server groups work constantly to make that easier and more robust to deploy in internal/corporate scenarios it remains an significant investment, certainly if only to support signing local code/solutions. But if one considers the investment from an secure communications perspective (IRM, S/MIME, SSL/TLS even internally, Document signatures, Smart card login etc. etc.) and a more general code security p.o.v (Windows Software Restriction policy, InfoPath forms solutions, and Macros/Office add-ins) then it becomes a more palatable thought.
Back to the question at hand, even with an internal PKI, for an “ad-hoc” workgroup, signing with an internal cert could be challenging. That’s the reason we worked to extend the Trust Locations model to allow you as the author for team members have a mechanism to deploy trusted solutions (say to a share that only you can write to but the team can read from) and avoid users having to “Enable” or navigate prompts. Once they add that location to their settings you can push new solutions etc. It does give you “ownership” of their machines, but you already have that today if you can talk them into saying yet to the macro prompt (or dropping their settings). Again ANYONE who can write to that location owns their machine, so it needs to be managed judiciously.
The MSDN pages don’t walk you through the process of getting a certificate because the process and stages vary from CA to CA, so it’s hard to manage all cases.
Joe:
Workbook_Open will be called once the user enables the macros. Yes this can break situations where the macros depend on the workbook being opened in an unmodified state. But this situation already exists for such code in Office 2003. If the user opens the book, chooses “Disable” on the notification, they can modify the book, change state or active cell locations and close the book. On next open, if they choose “Enable” the macros now have a modified state to work with.
Realistically such solutions are fragile, and other than making the code more robust, it would at least be better to ensure the book is trusted (signed with a cert pushed to the trusted publisher store or published to a trusted location) such that the user does not run the risk of getting in this situation.
Sam:
We like to think there’s at least one reason no-one bothers with Macro viruses today, and that because of the steps we took to secure running macros J, though improved AV techniques and “trends” have helped too.
It’s interesting to note that OpenOffice recently attracted some attention because of issues w.r.t. macro security. arstechnica.com/.../20060718-7288.html
Just because it’s not the “cool” place to be, doesn’t mean we can let our guard down. Indeed as we see more and more attacks being “financially” motivated rather than for “attention” we can’t relax in any aspects of the security model.
To converting to an .EXE, it’s true that will by-pass the macro security. But you now turn to whole other set of security models in Windows, IE etc. to defend against running that form of code (or ensuring the user makes the correct decision to allow it install/run).
On a) Office2007 uses 128 Bit AES encryption for password protection with the new Open XML formats, you can also change the default encryption for both Open XML and legacy formats using registry/policy keys.
On b) I don’t know what backdoors you refer too..?
Olala:
Your name a reference to Space Channel 9? Awesome, on to your question: There may be a little confusion here between a “valid” signature where the certificate of the signer is verified (which we always do before given you information about the signature) AND the actual user decision to “trust” that entity identified by the valid certificate.
In case where the certificate is tampered with or “not valid” we don’t actually allow you enable the code AT ALL. The user is informed that the signature is invalid and all they can do is disable the code.
In the case where the certificate is valid, then in essence we ARE saying the code is signed by Microsoft, and the decision to the user is to trust Microsoft (either for this one case, or for ALL code from Microsoft.) or not.
Certainly there is merit in the caution around “claims to be Microsoft” (or any entity) where an attacker has managed to get a “real” Microsoft private key, but at that point we are into threats that undermine the whole PKI (Public Key Infrastructure) and trying to reflect that into a user decision is probably not helpful since it would be almost impossible for the user to identify such an attack (unless they verify cert thumbprints etc.) So in the interests of simplicity we stick to saying a valid cert is from the claimed publisher.
Harlan Grove:
With respect to the comment on Trusted Locations being a security risk. Yes it’s true that any way to bypass the security checks needs to be treated cautiously, it’s a balance we are trying to strike (dropping security settings to run all macros would be worse). That’s why we don’t trust locations in the network by default you have to opt in. It’s why we don’t trust sub folders by default. It’s why we won’t let you trust your TIF where attachments are written or trust your entire disk.
Also all our help material talks about creating “Specific” locations to Trust, rather than trusting say the whole of “My Documents”. But it’s accurate that these needs to be managed carefully especially in the network case w.r.t. who can write to them.
That said, I do think saying any trusted location is a “huge security hole” is a bit strong. Trusted locations work as long as the security boundary to your machine is maintained. If an attacker can write files to your machine, independent of Office Trusted locations you are already in trouble. Indeed why write to an Office location and try to get the user to open a file from there, why not write to the Windows Startup folder where you guaranteed to get to run.
For those admins that are worried you can remove or lock down the locations trusted on a users machine using policy.
SteveA:
See the comments on Trust locations for use in an Ad-hoc working group. You could have your co-worker create a specific trusted location on their machine to which they add solutions from you. Or you could create a network share you have write permissions to, and from which they can only read and publish solutions there. Again manage those locations judiciously.
A User:
In all our help material we explicitly advise folks not to trust “My Documents” but rather create a separate location in there for solutions. Admins also have the ability to lock down trusted locations for users. And as I said earlier, if someone can write to a folder on your machine you are already in trouble. The Office trusted locations add to the risk, but we don’t believe it’s so great that it outweighs the other common behavior of changing settings to allow ALL macros to run irrespective of location.
In the case where you don’t want to trust Microsoft as a publisher, then you can choose not to do that and make the decision on a case by case basis. It does mean for things like macros in templates etc. you will be prompted every time unless you do things like add files to the Templates folder which is trusted by default. The Trusted Publisher list can also be managed by policy and it’s important to note that Office shares that list with IE (and the Software Restriction Policy settings also).
Comments: (loading) Collapse