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 - Install Before Execute
Luigi Lo Iacono, Peter Nehren
January 18, 2016
Install Before Execute
| Name | Install Before Execute |
| Sources | (Garfinkel, 2005), (Kirovski et al., 2003), (Reid, 1990) |
| Synonyms | None |
| Context | Many worms, viruses and other programs are inadvertently run by users who are trying to open them. Others take advantage of operating system bugs and run autonomously. Some kinds of “malware” attacks use features in browsers to download executables to the user’s desktop; these executables are sometimes inadvertently run by a user who is trying to “open” them. |
| Problem | How to avoid that malicious software is installed? |
| Solution | Ensure that programs cannot run unless they have been properly installed. |
| Examples | PalmOS will not run an application unless it is installed, but the installation process is trivial.  Source: (Garfinkel, 2005) |
| Implementation | A permission-based system simply prohibits code from running that is not located in the correct directory or without having the correct permission bits set; such directories and bits could only be written through the installation process. Other approaches are possible. |
| Consequences | Viruses and worms delivered by email cannot be run unless they can trick the user into installing them. Some implementations of Install Before Execute will foil binary exploits. |
| Dependencies | None |
| Relationships | [Distinguish Between Run and Open] |
| Principles | [Path Of Least Resistance] |
| Guidelines | None |
| Check lists | None |
| Use cases | None |
| Tags | Install Before Execute, Distinguish Between Run and Open, Expectation Conformity, Access Control, Fail Safety |
| 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.
Kirovski, D., Drinic, M., Potkonjak, M., Kirovski, D., 2003. Enabling trusted software integrity.
Reid, B., 1990. Computers under attack: Intruders, worms, and viruses, in: Denning, P.J. (Ed.),. ACM, New York, NY, USA, pp. 145–149. doi:10.1145/102616.102626