Section 30.4. User Control of Active Content Security

30.4. User Control of Active Content Security

Developers, administrators, and users are all involved in making (or avoiding) security decisions. Developers determine many of the decisions available to (or imposed on) administrators and users, and administrators do the same for their users. Users have the most context for making those decisions, but have the least time (and often the least experience) for thinking about security impacts and risks. Conversely, any security-related decision not made available to the user or administrator is one less way they can protect themselves.

All of these considerations inform the design of security features. In addition, security features should be policy neutral. They should ensure that the system is securable, but not impose a particular security policy on it. However, any security-related decisions that are made available to users need to have a default behavior chosen for them. Users may find it difficult to evaluate why the default might not be right for them.

Choice of the default will determine how open or secure the feature is. Defaults can have a large impact on both the usability and the security of a system. Open defaults have traditionally allowed security and usability concerns to remain unaddressed, because the security features were not part of the initial user experience of the system. They have also allowed users to deploy systems in an unsecured state, increasing the chance of successful attacks.

When protections on active content were introduced into version 4.5 of Notes, the default shipping policy was open. Any active content, whether signed or unsigned, would be executed. This was in part to ease the transition; active content shipped before that version had no policy controls at all, and no signatures. Administrators could change that default for users before they installed, and could specify whether users had the ability to change their own Execution Control List (ECL) policy. Subsequent administrative updates could be enabled by supported application template programming extensions that provided an ECL update via some other frequently accessed Notes application (such as email) or with a specific button that the user had to click (which could be shared via email). In practice, as with many administrative security features, the shipped defaults were widely deployed. As organizations gained experience with the feature, they came to understand that security would be enhanced with tighter policy.

30.4.1. Deployment Study

When we changed to a secure default ECL policy in R5.02e, we were able to observe both the usability of the active content controls and how easily they can be used to ensure secure behavior on the part of users. We studied a 500-person organization securing their ECL defaults (we call them SoftwareHouse).^[9] After the administrative ECL was secured at SoftwareHouse, a prestigious security guru sent email to everyone in the company. The email included a button for a user to click to tighten his ECLs from the new administrative defaults, as well as an extensive explanation of those new secure defaults. It also provided an example of an unsigned Execution Security Alert (which notifies users that unsigned active content is trying to run on their system), explaining the potential danger it could represent, and giving instructions about how users who received such alerts should handle them safely and to whom they should report these alerts.

^[9] Mary Ellen Zurko, Charlie Kaufman, Katherine Spanbauer, and Chuck Bassett, "Did You Ever Have to Make Up Your Mind? What Notes Users Do When Faced with a Security Decision," 18th Annual Computer Security Applications Conference (2002), 371381.

Three months later, we performed a test. We used active content in a survey email to obtain data on the state of ECLs in SoftwareHouse. Users received mail from another colleague at SoftwareHouse, also from the security team. This mail message included unsigned active content, which users had been warned about in the previous email. The active content sent mail back to the person who sent the mail (Jane Doe). If a user opened this second mail and had unsecured ECL settings, the response email was sent on behalf of the recipient to Jane Doe with no user interaction. If the user opened this second mail message and had secured policy settings that disallowed unsigned active content, they saw two unsigned ECL alerts mapping to the two operations necessary to send the response email. Choosing to allow unsigned active content to run is not the default on those dialogs. However, if they overrode the default and allowed the active content to run, a response mail was also sent to Jane Doe. The response mail message had a timer indicating the amount of elapsed time between the two operations, to differentiate between the unsecured policy and the overridden secure policy cases. We also attempted to gather self-reported statistics on who did not allow the unsigned active content to run. The text of the mail message explained the survey and encouraged people who didn't allow the unsigned code to execute to send the contact person mail telling him so, for data-gathering purposes. We called that list of people the Gold Star list to further encourage self-reporting.

We found that 62% of the people on the email list (334) responded within two days of the survey. In addition, 68% of the respondents (227) had secured their defaults to not allow unsigned code to run on their behalf, and 31% of the respondents (102) had open ECL defaults. This number demonstrates that many users in this fairly computer-savvy population would, in fact, take an explicit action to secure themselves when asked to do so by someone they know and trust who explains the request.

We also found that 71% of the responses (237), or 44% of the entire recipient list, allowed the unsigned active content to run, either because their defaults were open or because they explicitly allowed it when the alert dialogs came up. This number clearly shows that if users must make explicit and informed choices that are likely to stop the flow of their work (instead of continue it) in order to maintain their security, many will not. This finding is related to recent trends showing how hopeless it is to tell users to practice good mail attachment hygiene to stop viruses.

30.4.2. Solutions and Challenges

Better administrative tools can take the burden of setting secure defaults off of the user. Domino 6 included policy management features that allowed administrators to push down updates to the ECL policy to users, without needing to ask the users to take an extra step (like clicking a button) or tying it to use of a particular Notes application. This tool allows administrators to achieve 100% compliance with the portions of the policy set by the administrator, under the constraints they choose. Administrators working in a very structured organization in which code signers are preauthorized can set their policy to override the user's policy whenever the administrative policy is changed, and disallow users from changing their local personal versions of the policy.

Unfortunately, many organizations don't work in a structure where all trustworthy active content creators are preauthorized. In fact, such a target is at odds with the desire to simplify the creation and reuse of simple active content (such as RSVP buttons). Some of the other usability features deployed in Domino can help with that model. ECL policy updates can be pushed down to the user on a daily basis, and can merge with, rather than override, user-specific settings. In combination with allowing users to change their own policy, this can be used to ensure that the most egregiously unsafe settings, such as the permissions allowed to unsigned active content, are done away with.