1. DEV391 Security and Deployment of Office Solutions Built with Visual Studio.NET Eric Carter Lead Developer Visual Studio Microsoft Corporation

2. Agenda Introduction Policy, Permissions and Evidence Security Model Deployment Options Wrap-Up

3. Introduction Visual Studio Tools for Office Adds Word and Excel solutions to Visual Studio 2003 Focus on document-centric solutions Does not replace VBA Same development model Different security and deployment

4. Policy Policies help us make decisions Governments - Foreign Policy Retailers - Exchange & Returns Policy Parents - Bedtime Policy :-) More than just technical measures The “human factor” Holistic approach Security Policy is a tool to help us protect assets

5. Office Security Policy No code runs by default Code may execute once it is explicitly trusted Once trusted, code has all the permissions of the current user No exceptions!

6. Office Policy in Effect demo demo

7. Permissions and Evidence Permissions grant access to things Evidence makes claims about things Conditions tie them together: To have P, you must prove C To prove C, you must present E Note: Permissions may have unintended consequences Evidence may not be trustworthy

8. Permissions and Evidence demo demo “Bob” and “Betty” The Bank

9. Hello, how can I help you? I’d like to withdraw $500 from my account, please I need to see some ID, please Sure…

11. Sorry, that is not good enough. Do you have anything else? Sure…

13. Great, here’s your $500 Thanks! Have a nice day!

14. Mapping to the CLR Permissions grant access to things Evidence makes claims about things Conditions tie them together: To access the registry, code must be “installed” To be “installed”, code must come from the MyComputer Zone Often expressed in reverse: If code comes from http://MyServer/, it is partially trusted If code is partially trusted, it can display UI and store temporary files

15. Office Specifics Office solutions built with the Visual Studio Tools require FullTrust FullTrust: All possible permissions Office does not honour default MyComputer Zone evidence Just like Bob’s hand-written note Therefore, you need stronger evidence Location Publisher or Strongname Hash

16. Trusting Documents Local documents trusted by default Network documents must be trusted before they can host code Code must also be trusted! Traditional evidence unsuitable Documents not easily “signed” Little control over content on shares OfficeDocumentMembershipCondition used to trust documents on shares Office provides evidence for documents

17. Policy Recommendations Trust a Publisher or Strongname within a Zone or specific location See Contoso example at end of deck Do… Err on the side of caution Plan for future projects Don’t… Trust generic folders like C:\ or “My Documents” Run as Administrator :-)

18. Setting up Policy demo demo

19. Deployment Models Document and assembly on client Non-admin installs Complete offline support  Hard to maintain / upgrade Document and assembly on server Easy maintenance  Admin-only installs  No offline ability Mixed model (recommended) Document on client, assembly on server  Good compromise between the two

20. Offline Support Office supports basic off-line scenarios Assembly is managed by the IE cache Users must connect to the network at least once to cache assembly Only HTTP locations are supported UNC shares are not cached User code must deal with offline state For example, no access to web services

21. Deploying Solutions Developers can set “Assembly Link Location” in Visual Studio Typically, code will be passed to an Administrator for signing / publishing Administrators use Persistence Control to update references Sample script in documentation Documents can be e-mailed or published independently of code

22. Deploying Policy Client machines must be updated before any Office solutions can run Ref: “Office Security Policy” :-) Several options for deployment: Manual changes by end users Logon scripts / setup programs Group Policy / SMS If you follow the guidelines, policy should only need updating infrequently

23. Deploying Solutions demo demo

24. Summary Office is secure by default Planning your policy is key Initial deploying may be tricky The payoff is in ongoing maintenance VBA is still there if you need it Don’t run as Admin :-)

25. Q & A Q & A

26. Community Resources MSDN Office Developer Centre: http://msdn.microsoft.com/office/ Newsgroups: For VS Tools-specific issues, use microsoft.public.vsnet.vstools.office microsoft.public.vsnet.vstools.office For Excel-specific issues, use microsoft.public.excel.programming microsoft.public.excel.programming For Word-specific issues, use microsoft.public.word.vba.general microsoft.public.word.vba.general For.NET security-specific issues, use microsoft.public.dotnet.security microsoft.public.dotnet.security

27. Community Resources http://www.microsoft.com/communities/default.mspx Most Valuable Professional (MVP) http://www.mvp.support.microsoft.com/ Newsgroups Converse online with Microsoft Newsgroups, including Worldwide http://www.microsoft.com/communities/newsgroups/default.mspx User Groups Meet and learn with your peers http://www.microsoft.com/communities/usergroups/default.mspx

28. evaluations evaluations

29. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.

30. Next Steps Download Visual Studio Tools for Office Beta msdn.microsoft.com/vstudio/office Build some of the samples Start thinking about how to integrate.NET policy into your organization’s security policy Experiment with deployment options in a test environment Visit us in the newsgroup!

31. Ask The Experts Get Your Questions Answered I will be available in the ATE area after this session

32. Appendix… The following slides provide additional details to complement the main slide deck.

33. Trusting Documents

34. Why Trust Documents? To protect against code re-purposing “Trusted Code” is not the same as “Safe Code” - all code has bugs Malicious users may exploit bugs Requiring documents to be trusted reduces the likelihood of the attack outlined on the next slide Similar to the Restricted Zone in IE – even though Flash is trusted, it can’t run within e-mail messages

35. Why Trust Documents? Typical repurposing scenario (blocked by the Office security policy) Contoso builds OfficeApp 1.0 and signs it Bob trusts the code and runs some documents Harry Hacker discovers a security bug in OfficeApp 1.0 He crafts a malicious document and sends it to Bob in e-mail Bob opens e-mail, code runs, and his machine is toast :-(

36. Sample Security Policy

37. Contoso Policy Example Contoso expects to deploy several low- trust web applications from http://webserver/ and other locations http://webserver/ They will host trusted Office assemblies from http://codeserver/http://codeserver/ They expect users to share documents on http://sharepoint/ and through the \\contoso\public\ share http://sharepoint/ \\contoso\public\

38. Contoso Policy Example The web apps are already covered by default policy – no changes needed The Office code will need to be trusted. Contoso doesn’t have PKI deployed, so they will use a strong name key instead The shared documents will also need to be trusted if they contain code

39. Contoso Policy Example Enterprise Policy, LF = LevelFinal  All Code  Everything  LocalIntranet  LocalIntranet  http://codeserver/  Nothinghttp://codeserver/  Contoso Key  FullTrust LF  OfficeDocument  Nothing  http://sharepoint/  FullTrust LFhttp://sharepoint/  \\contoso\public  FullTrust LF\\contoso\public

40. Contoso Policy Example The Contoso key is only trusted from the codeserver site Protects against leaked buggy code Allows future deployments to same server Only Office documents are trusted on sharepoint and contoso\public Since users can upload arbitrary files, don’t want to trust the entire server LevelFinal is used to stop further evaluation at Machine level (which would revoke permissions)

41. Policy Deployment Options

42. Manual Changes by Users Good for small deployments or to savvy users in an unmanaged environment Pros: No additional dev work :-) Cons: End-users run GUI tools or caspol Bad user experience; tricky to get right Social engineering attacks become easier; users “trained” to trust code Only local assemblies can be trusted Administrator needed for network locations

43. Logon scripts / Setup app Good for deployments to desktops in a domain where users are Administrators Pros: Removes burden from the end user Cons: Requires additional development work Only local assemblies can be trusted Administrator needed for network locations

44. Group Policy / SMS Great for large, managed organisations Pros: Minimal dev work No end-user impact Users don’t need to be Administrators to trust network assemblies Cons: Replaces existing policy; no “update” mode Make use of the ‘Enterprise’ level to avoid conflicts with user settings Requires relevant infrastructure

45. Community Resources http://www.microsoft.com/communities/default.mspx Most Valuable Professional (MVP) http://www.mvp.support.microsoft.com/ Newsgroups Converse online with Microsoft Newsgroups, including Worldwide http://www.microsoft.com/communities/newsgroups/default.mspx User Groups Meet and learn with your peers http://www.microsoft.com/communities/usergroups/default.mspx

46. evaluations evaluations

47. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.