Notes Execution Control List (ECL) User Study Construction Kit
Mary Ellen Zurko, IBM Software Group
Homepage URL: http://mysite.verizon.net/resqwf60/
In November 1999 we conducted an “in the wild” study of the ability of sites and users to set and adhere to secure defaults for their Notes protections on active content, called Execution Control Lists (ECLs).
Much of the background of the study is in “Did You Ever Have To Make Up Your Mind?: What Notes Users Do When Faced With A Security Decision”, Mary Ellen Zurko, Charlie Kaufman, Katherine Spanbauer, and Chuck Bassett, 18th Annual Computer Security Applications Conference (ACSAC), 2002. http://www.acsac.org/2002/papers/7.pdf
Most of what we have and can share (since we need to blind the identity of the participating company) is in fact in the paper. This document restates and restructures that information to follow the categories suggested in the SOUPS workshop call, and adds some detail in the background of the scenario.
Scenario
The Notes ECL study was an in context study of the deployability of securing the default settings by not granting any privileges to unsigned active content. Mechanisms at the time did not automatically propagate them to the user population. There was disagreement in the Notes development organization over whether or not the support in plan for 5.02 was sufficient to deploy ECLs securely. We ran this study to get data on that point on that topic. Best practice at the time was to set the administrative defaults securely then construct a button that users press to refresh their personal settings from it.
We ran the study at a small company that did Notes-related development, which we call SoftwareHouse for anonymity purposes.
A prestigious SoftwareHouse security maven sent an email announcement to a list that included everyone in the company, and posted the same announcement in a Notes discussion database that everyone had access to. Below is the email message, with parts removed and described in []’s to preserve anonymity.
Initial Email Message
Subject: Please Push This Button!
At the bottom of this note is
a request that you push a button. The rest of the note is an explanation as to
why you should do it and what changes you should expect to see as a result.
I'm from Security and I'm here to help you.
This note has
an ominous tone, but be assured that most people who do ordinary things will
not be affected by this at all.
[The maven made a motivating
statement about better security.]
When some people say
"better security", they mean that it's harder to break things. Others
mean "it doesn't get in my way" (like proximity badges over door
keys). Most products allow users and/or administrators to trade off convenience
and security. When I say "better security", I mean that those
tradeoffs are more palatable: you can get more convenience for a given level of
security or more security for a given level of convenience.
[The maven introduced the
notion of administration and user customization and defaults.]
As we learn to live in a more
hostile world, we need to change those defaults to be more secure even if less
convenient.
[We need to focus attention on
getting more convenience with our security.]
The button below will switch
one aspect of your environment [...]. We have been using this in the
security group for a while, would now like to [deploy across] all of SystemHouse. [...].
There are a
new family of mail bourne computer viruses
springing up. Melissa is the best known. Explore.zip
did some real damage in Iris a while back. They work by sending email
containing executable code and tricking the user into running it. Our first
line of defense against such attacks is the Execution Control List, or ECL.
Mailing around executable code and running it automatically is a really handy
tool, and makes many advanced Notes applications possible. An ECL specifies who
you trust to have created such code and what you trust them to do. By default,
users trust everyone for everything, and extremely dangerous state. The button
below will update your ECL to only trust the people who we know have
intentionally created executable content in our environment. After you push it,
you will be warned any time a button you push or a form you view a document
through tries to do something unexpected. An example of what you'll see is this
pop up:
You will see this if you push
the "Update ECL" button twice, because it's a dangerous operation and
after pushing it you'll be warned about such things...
SoftwareHouse is unusual in that we run a
lot of experimental stuff created by a lot of people. If you examine your ECL
after you update it, you'll see a lot of SoftwareHouse
folk listed. By prepopulating your ECL with these
people, you'll avoid a lot of unnecessary warnings. If you get warnings like
the above and they are signed by a SoftwareHouse person,
you should push the "Trust Signer" button, which adds that person to
your ECL so that you won't be warned again. You may then be asked whether you
want to trust */ SoftwareHouse, and you should say
no. The reason not to give blanket trust to */ SoftwareHouse
is that if one person is infected with a virus, that virus could send itself
from that person and infect the rest of us. People who regularly create
executable content should be especially careful about executable content
themselves for this reason.
If you get something (like the
above) that has "Signed by: -No Signature-", it represents either a
bug [...] or an actual attack. You should never say "Trust Signer" in
this case [...].To continue (albeit unsafely), push the "Execute
Once" button. If you want to be safe, push "Abort" and only the
safe parts of the requested operation will occur. [Instructions for how to
report if you see this, and to who.] There are some
known bugs that produce this problem, including cutting and pasting buttons
(this one) and using "Notes with Internet Explorer" as your default
browser (use "Internet Explorer" as the closest alternative until the
bug is fixed).
The moment of truth:
Welcome to the future. If
you're curious, you can look at your ECL before and after with Examine ECL. You
can always go back by going to "File... Preferences... User Preferences...
Security Options..." and checking all the boxes for the
"Default" and "No Signature" names. But please
don't. I mention it only so you won't be afraid to take the plunge.
(Push This One)
["Update ECL" button]
(Then push this if you're curious what the first
one did)
["Examine ECL" button]
p.s. I could have created this form so that if you weren't
secure, this form would make it happen without warning or telling you... an
anti-virus virus. That still may happen someday, but it seemed unfriendly.
The follow up
survey
Three months later, we used active content in a survey email to obtain data on the state of ECLs in SoftwareHouse.
Users saw new mail from their colleague Jane Doe/SoftwareHouse, with the subject "Important Information". When they opened the email (or when they selected it with the preview pane that displays message content enabled), if their ECLs did not allow unsigned code the ability to access another database, a "-No Signature-" Execution Security Alert came up, covering up much of the content of the mail message. Because the technology needed to send this active content, the top quarter of the displayed message was missing the Notes mail look and feel of a formatted header section with the sender's name on the left hand side and the To:, CC:, BCC: and Subject: fields on the right hand side, in fields.
They could move that dialog, or dismiss the alert with one of the buttons. If they glanced down at the bottom edge of the Notes client, they would have seen the status message "Signed by Jane Doe/SoftwareHouse on 11/22/1999 02:20:46 PM, according to /SoftwareHouse".
If they responded with "Execute Once" or "Trust Signer", and if their ECL did not allow unsigned code to send mail on their behalf, a second alert would appear (see below). Dismissing that dialog in any way finished uncovering the content of the mail message.
Anonymized text of the mail message is below. The person who sent the survey was a SoftwareHouse security person more junior than the one who had sent the original email with the instructions on securing ECLs. It went to the same list that had been used to send the earlier mail message.
Subject: Important Information
Dear colleague,
I'm Jane Doe, from the SoftwareHouse security group.
In an effort to determine how useful and effective our efforts have been in
asking all of you to tighten up your workstation ECLs,
we are collecting data on whether anyone here at SoftwareHouse
still allows unsigned code to automatically execute on their workstation (and
whether anyone who doesn't would still allow unsigned code of dubious origin to
execute).
If your workstation ECL is still wide open, you did not see any alerts when you
viewed this message, and you have sent me email telling me that you allow
unsigned code to execute on your workstation. If you did see the alerts, and
you allowed unsigned code to execute by pressing the "Execute Once"
or "Trust Signer" buttons on those two Execution Security Alerts, you
also sent me that message. If you routinely let hostile code execute in this
fashion, the consequences could have been much worse (such as erasing your hard
drive or leaking Product Y development secrets).
If you saw the alerts and aborted the code execution, thank you. You can
further help us by sending me (Jane Doe) email telling me that you did that,
allowing me to add you to our Gold Star list of colleagues who practice good
ECL hygiene.
Thank you for participating in our study. Feel free to send me any questions or
concerns.
Jane Doe
Method of sampling user population
Both emails were sent to all employees of SoftwareHouse. We used the responses from the first two days as the results. Users with unsafe ECLs (or the practice of overriding them unsafely) who opened the second mail message within 2 days automatically responded. Users treating unsigned active content securely had to self report, and were encouraged to do so in the mail message, by both explicitly requesting it and telling them where to send mail, and by telling them they would be members of the “Gold Star” list if they did so.
Responses dribbled in for up to two months after the mail was sent; they are not included in our discussions of the results. 62% of the people on the email list (334) responded within two days of the survey.
Code
The Lotuscript in the survey email follows:
Sub Postopen(Source As Notesuidocument)
On Error Resume Next
Dim current As String
current$ = Time$()
Dim sess As New notessession
Dim
db As notesdatabase
Set db = sess.currentdatabase
Dim doc As New notesdocument(db)
doc.SendTo="Jane
Doe/SoftwareHouse"
doc.Subject
= "I allow unsigned code to execute on my workstation " + current +
"; " + Time$()
Call doc.send(False)
End Sub
It sets up the variables needed to send email, which includes creating a new document in the user’s mail database. Creating that document checks ECL protections on accessing the database the active content is in. If the ECL allows that operation by unsigned code, the execution path to the line setting the subject with both the beginning and current time will show almost no difference. If instead the user’s ECLs are safe, but they allowed the active content to progress via the alert dialog, the difference in the two timestamps was noticeable at the granularity of seconds. The final line of code sends the constructed email, and brings up a second ECL alert if their defaults are safely configured, giving the user a second chance to abort the sending of the mail.
Measurement techniques and Instrumentation design
The user population sampling and code sections above give background on how we instrumented and measured the results of the survey. We were able to differentiate between users who had secure defaults and those that overrode those defaults via the alert dialog through the timestamp. Users who practiced safe computing were encouraged to self report.