If your security architecture is highly restrictive and you want to help minimize the potential risk from ActiveX controls, you can disable ActiveX controls. Disabling ActiveX controls prevents all ActiveX controls in a file from initializing (that is, loading) when a file is opened. In some cases, a disabled ActiveX control might appear in a file as a red x or some other symbol, but the control is disabled and no action will occur if a user clicks the symbol. Also, when you disable ActiveX controls, users are not notified that ActiveX controls are disabled.

To disable ActiveX controls, configure any one of the settings as recommended in the following table.

Note:
ActiveX controls cannot be disabled in files that are saved in trusted locations. When a file is opened from a trusted location, all active content in the file is initialized and allowed to run without notification even if you disable ActiveX controls.

If you disable ActiveX controls, be sure that you:

• Notify users that ActiveX controls are disabled and that no notifications will appear when they open files that contain disabled ActiveX controls.

• Test the effect that disabling ActiveX controls might have on your organization. Because many Office solutions are built with ActiveX controls, disabling ActiveX controls can cause unexpected behavior and prevent applications from working properly.

• Record the settings in your security planning documents and in your security operations documents.

You can configure the 2007 Office system so that all ActiveX controls initialize and run without notification. This can be useful in some test and development environments, and in isolated environments where supplemental security mechanisms such as firewalls, virus detection programs, and intrusion detection programs help ensure that files do not contain malicious content.

Important:
We do not recommend that you allow ActiveX controls to initialize and run without warning in a production environment. Allowing ActiveX controls to initialize and run without warning can substantially increase your risk of attack and potentially weaken your organization's security.

To allow ActiveX controls to initialize and run without notification, configure any one of the settings as recommended in the following table.

When you change the setting, SFI and UFI controls are initialized with minimal restrictions (that is, with persisted values). If persisted values are not available, the controls are initialized with default values by using the InitNew method. SFI controls are initialized in safe mode, and users are not notified that ActiveX controls are enabled. This setting can be configured only with the 2007 Office system Administrative Templates (.adm files). This setting applies to the 2007 Office system and earlier versions of Office.

For a list of all configurations, see the 2007 Microsoft Office Security Guide (Threats and Countermeasures: Security Settings in the 2007 Office System) (http://go.microsoft.com/?linkId=7711534).

If you allow all ActiveX controls to initialize and run without notification, be sure that you:

• Notify users that ActiveX controls are enabled and that no notifications will appear when they open files that contain ActiveX controls.

• Record the settings in your security planning documents and in your security operations documents.

The 2007 Office system provides several settings that enable you to control the way ActiveX controls are initialized based on SFI, UFI, and safe-mode parameters. SFI, UFI, and safe mode are parameters that developers can configure when they create ActiveX controls. ActiveX controls that are marked SFI use safe data sources to initialize. A safe data source is one that is trusted, known, and does not cause a security breach. Controls that are not marked SFI are considered to be UFI.

Safe mode is another security mechanism that developers can use to help ensure the safety of ActiveX controls. When a developer creates an ActiveX control that implements safe mode, the control can be initialized in two ways: in safe mode and in unsafe mode. When an ActiveX control is initialized in safe mode, certain restrictions that limit functionality are imposed on the control. Conversely, when an ActiveX control is initialized in unsafe mode, there are no restrictions on its functionality. For example, an ActiveX control that reads and writes files might only be allowed to read files if it is initialized in safe mode, and it might be able to read and write files when it is initialized in unsafe mode. Only ActiveX controls that are SFI can be initialized in safe mode. ActiveX controls that are UFI are always initialized in unsafe mode.

By default, ActiveX controls are initialized as follows in the 2007 Office system:

• If a file contains a VBA project, users are prompted to enable or disable the ActiveX controls that are in the file. If users choose to enable the ActiveX controls, all SFI and UFI controls are initialized with minimal restrictions (that is, with persistent values). If persistent values are not available, the controls are initialized with default values by using the InitNew method. SFI controls are initialized in safe mode.

• If the file does not contain a VBA project, and the file contains only SFI controls, the SFI controls are initialized with minimal restrictions (that is, with persistent values). If persistent values are not available, the controls are initialized with default values by using the InitNew method. SFI controls are initialized in safe mode.

• If the file does not contain a VBA project, and the file contains both SFI and UFI controls, users are prompted to enable or disable the ActiveX controls that are in the file. If users choose to enable the ActiveX controls, SFI controls are initialized with minimal restrictions (that is, with persistent values), and UFI controls are initialized with default values by using the InitNew method. SFI controls are initialized in safe mode.

If this default behavior is not adequate for your organization but you do not want to disable ActiveX controls, you can strengthen the way ActiveX controls are initialized by forcing UFI controls to be initialized with default values instead of minimal restrictions when a file contains a VBA project. To do this, configure either of the following settings as recommended in the following table.

You can configure ActiveX control settings to accommodate many more security scenarios. For more information about ActiveX control settings in the 2007 Office system, including descriptions of all settings and a comparison of OCT, Group Policy, and Trust Center settings, see Security policies and settings in the 2007 Office system. For more information about configuring ActiveX control settings, see Configure security settings for ActiveX controls, add-ins, and macros in the 2007 Office system.

If your security architecture is highly restrictive and you want to help minimize the potential risk from add-ins, you can disable add-ins. When you disable add-ins, you prevent add-ins from running, and users are not notified that add-ins are disabled.

You cannot globally disable add-ins. You can disable add-ins only on a per-application basis for the following applications:

• Microsoft Office Access 2007

• Microsoft Office Excel 2007

• Microsoft Office PowerPoint 2007

• Microsoft Office Publisher 2007

• Microsoft Office Visio 2007

• Microsoft Office Word 2007

To disable add-ins, configure either of the settings as recommended in the following table.

If you disable add-ins, be sure that you:

• Notify users that add-ins are disabled.

• Record the settings in your security planning documents and in your security operations documents.

If you do not want to disable add-ins, but you still want to increase the security of add-ins, you can require that add-ins are signed by a trusted publisher. When you do this, the following behavior occurs:

• Trusted add-ins run without notification. A trusted add-in is an add-in that is saved in a trusted location or an add-in that is signed by a publisher that is on the Trusted Publishers list.

• Unsigned add-ins are disabled, but users are prompted to enable or disable the add-ins.

• Add-ins that are signed by a publisher that is not on the Trusted Publishers list are disabled, but users are prompted to enable or disable the add-ins.

You cannot globally configure a setting that requires add-ins to be signed by a trusted publisher. You must configure this setting on a per-application basis, and you can configure it for only the following applications:

• Office Access 2007

• Office Excel 2007

• Office PowerPoint 2007

• Office Publisher 2007

• Office Visio 2007

• Office Word 2007

To require that add-ins are signed by a trusted publisher, configure either of the settings as recommended in the following table.

Be sure to record these settings in your security planning documents and in your security operations documents.

Even if you require that add-ins be signed by a trusted publisher, users can still enable unsigned add-ins through the Message Bar. If you do not want users to enable unsigned add-ins, you can disable notifications for unsigned add-ins. You can do this only on a per-application basis, and you can configure it for only the following applications:

• Office Access 2007

• Office Excel 2007

• Office PowerPoint 2007

• Office Publisher 2007

• Office Visio 2007

• Office Word 2007

To do this, configure either of the settings as recommended in the following table.

If you disable notifications for unsigned add-ins, be sure that you:

• Notify users that unsigned add-ins are silently disabled.

• Record the settings in your security planning documents and in your security operations documents.

For more information about add-in settings in the 2007 Office system, including descriptions of settings and a comparison of OCT, Group Policy, and Trust Center settings, see Security policies and settings in the 2007 Office system. For more information about configuring add-in settings, see Configure security settings for ActiveX controls, add-ins, and macros in the 2007 Office system.

The 2007 Office system provides several settings that enable you to change the default behavior of macros. By default, trusted macros are allowed to run without notification. This includes macros in documents that are saved in a trusted location, and macros that meet the following criteria:

• The macro is signed by the developer with a digital signature.

• The digital signature is valid.

• This digital signature is current (not expired).

• The certificate associated with the digital signature was issued by a reputable certification authority (CA).

• The developer who signed the macro is a trusted publisher.

Macros that are not trusted are not allowed to run until a user clicks the Message Bar and chooses to enable the macro. (Some applications do not have a Message Bar; in these cases, notifications appear in dialog boxes.)

Note:
The default security setting for macros is different in Microsoft Office Outlook 2007. For more information, see the Office Outlook 2007 security documentation.

If the default security settings for macros do not meet the needs of your organization, you can do either of the following:

• Disable untrusted macros without notification.

• Disable notifications for unsigned macros, but allow notifications for signed macros.

Disable untrusted macros without notification

Disable notifications for unsigned macros

The 2007 Office system provides two settings that enable you to control the way VBA behaves. By default, VBA is enabled, if it is installed, and Automation clients do not have programmatic access to VBA projects. You can change this behavior in the following ways:

• You can provide Automation clients programmatic access to VBA projects.

• You can disable VBA.

In addition to these security settings in the 2007 Office system, Office Visio 2007 provides several settings that enable you to control the way VBA behaves in Office Visio 2007. For more information, see Security policies and settings in the 2007 Office system.

Provide Automation clients programmatic access to VBA projects

When you provide Automation clients programmatic access to VBA projects, Automation clients have the ability to use the VBA object model.

To provide Automation clients programmatic access to VBA projects, configure the setting that is described in the following table. This setting must be configured on a per-application basis, and can be configured for the following applications:

• Office Excel 2007

• Office PowerPoint 2007

• Office Word 2007

Setting name	Recommended configuration	Description
Trust access to Visual Basic project	Select this option: Disabled	By default, Automation clients do not have programmatic access to VBA projects. When you select this option, Automation clients can programmatically access the VBA object model. This setting can be configured in the OCT and with the 2007 Office system Administrative Templates (.adm files).

Important:
If you provide Automation clients programmatic access to VBA projects, you can increase your risk of attack from unauthorized programs that build self-replicating code.

Disable VBA

The 2007 Office system provides a single setting that enables you to control the way macros behave when they are run in an application that is started programmatically through Automation. Automation is a programming tool that allows developers to access the functionality of one application from another application. For example, a developer could create a project management application that uses the e-mail features and scheduling features of Office Outlook 2007. By default, when an application uses Automation to start an application in the 2007 Office system, macros are enabled and allowed to run without any security checks. You can change this behavior in two ways:

• You can disable macros in the application that is started programmatically. When you do this, users are not notified that macros are disabled and users are not prompted to enable or disable macros. This setting is useful if your organization has a restricted security model and you do not allow users to run macros.

• You can run macros according to the security settings that are configured in the application that is started programmatically. When you do this, macro behavior is dictated by the security settings that are configured in the application that is started programmatically. For example, if you require that all macros be digitally signed in Office Excel 2007, and an application uses Automation to start Office Excel 2007, macros will not run unless they are digitally signed. This setting is useful if you want your organization's security settings for macros to extend to applications that are started through Automation.

To change the default behavior of macros in applications that are started programmatically through Automation, use either of the settings that are recommended in the following table. You can configure these settings in the OCT and with the 2007 Office system Administrative Templates (.adm files). These settings are global and apply to the following applications:

• Office Excel 2007

• Office PowerPoint 2007

• Office Word 2007

If you change Automation security settings, be sure that you:

• Thoroughly test all of your applications to be sure that your change does not cause unpredictable behavior or limit functionality in an application. Some applications use Automation to silently start applications in the 2007 Office system.

• Record the configuration settings in your security planning documents and in your security operations documents.

In addition to these security settings in the 2007 Office system, Office Publisher 2007 provides a setting that enables you to configure Automation security for macros in Office Publisher 2007. For more information, see Security policies and settings in the 2007 Office system.

The 2007 Office system provides several settings that enable you to prevent encrypted macros from being scanned for viruses. This is useful if your virus-scanning program does not support the Microsoft Antivirus application programming interface (API).

By default, macros are encrypted when you encrypt and save a file in the Office Open XML Formats file format. If your virus-scanning program does not support the Microsoft Antivirus API, your virus-scanning program cannot scan encrypted macros. As a result, encrypted macros will be disabled. To prevent your antivirus program from scanning encrypted macros, configure the settings as recommended in the following table.

If you change the default settings for scanning encrypted macros, be sure that you:

• Record the settings in your security planning documents.

• Record the settings in your security operations documents.