Patterns
- Active Warnings
- Attractive Options
- Complete Delete
- Conveying Threats & Consequences
- Create a Security Lexicon
- Create Keys When Needed
- Delayed Unrecoverable Action
- Detailed Notifications About Security
- Direct Access to UI Components
- Disable by Default
- Disable of Services
- Disclose Significant Deviations
- Distinguish Between Run and Open
- Distinguish Internal Senders
- Distinguish Security Levels
- Email-Based Identification and Authentication
- Explicit Item Delete
- Explicit User Audit
- Failing Safely
- General Notifications About Security
- Immediate Notifications
- Immediate Options
- Indirect Access to UI Components
- Informative Dialogues
- Install Before Execute
- Key Continuity Management
- Levels of Severity
- Leverage Existing Identification
- Localization of Specific Areas
- Migrate and Backup Keys
- Noticeable Contextual Indicators
- Providing Recommendations
- Quick Description of UI Components
- Redundant Notifications
- Reset to Installation
- Restricted Areas Notification
- Security Features Used by the System
- Security Features Used by the User
- Send S/MIME-Signed Email
- Separating Content
- Sequential Access to UI Components
- Suggestive Dialogues
- System’s Security Tasks
- The Absence of Indicators
- Track Received Keys
- Track Recipients
- Warn When Unsafe
Patterns are based on scientific sources.
Usable Security Pattern - Distinguish Between Run and Open
Luigi Lo Iacono, Peter Nehren
January 18, 2016
Distinguish Between Run and Open
| Name | Distinguish Between Run and Open |
| Sources | (Garfinkel, 2005), (Yee, 2002), (Yee, 2004) |
| Synonyms | None |
| Context | Many worms pose as application documents. Victims try to open the document to see what it says, and instead end up running the hostile program. Distinguishing between these two acts with different gestures prevents the attack. |
| Problem | How to avoid that malicious software is executed when a file is opened? |
| Solution | Distinguish the act of running a program from the opening of a data file. |
| Examples | DOS and the Unix command-line shells distinguish between running a program and opening a document by explicitly requiring that the name of the application be provided when a document is opened: e.g., % emacs myletter.tex. Although this pattern does not recommend returning to the days of command-line interfaces, the fact that such interfaces were widely used and continue to be used indicates that such interfaces are in fact workable.  Source: (Garfinkel, 2005) |
| Implementation | On operating systems with a desktop metaphor, the double-click on an icon gesture can be changed so that double-clicking on an installed application runs the program, while double-clicking on an application that has not been installed causes the display of a warning message or suitable dialogue. |
| Consequences | Worms like the Love Letter (Nazario, 2004) and Melissa (Nazario, 2004) should be less likely to propagate. Spyware that is downloaded to the user’s desktop that masquerades as a document will be less likely to be installed. |
| Dependencies | None |
| Relationships | [Install Before Execute] |
| Principles | [Trusted Path] |
| Guidelines | None |
| Check lists | None |
| Use cases | None |
| Tags | Distinguish Between Run and Open, Fail Safety, Expectation Conformity |
| Log history | [01/18/2016]: Added to repository |
References
Garfinkel, S.L., 2005. Design principles and patterns for computer systems that are simultaneously secure and usable (PhD thesis). Massachusetts Institute of Technology.
Nazario, J., 2004. Defense and detection strategies against internet worms, Artech house computer security series. Artech House.
Yee, K.-P., 2004. Aligning security and usability. IEEE Security and Privacy 2, 48–55. doi:10.1109/MSP.2004.64
Yee, K.-P., 2002. User interaction design for secure systems, in: Proceedings of the 4th International Conference on Information and Communications Security, ICICS ’02. Springer-Verlag, London, UK, pp. 278–290.