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 - Disable by Default
Luigi Lo Iacono, Peter Nehren
January 18, 2016
Disable by Default
| Name | Disable by Default |
| Sources | (Garfinkel, 2005), (Microsoft, 2003) |
| Synonyms | None |
| Context | Contemporary operating systems are incredibly rich in the features and services that they offer. Without the adoption of Disable Services by Default, these services are enabled and present a security risk. The risk is magnified when new services are added as a result of installing new software or upgrading an operating system. In these cases, the new services should be disabled by default so that an upgrade does not create a new security vulnerability. |
| Problem | How to prevent security risks due to enabled but unused services? |
| Solution | Ensure that systems does not enable services, servers, and other significant but potentially surprising and security-relevant functionality unless there is a need to do so. |
| Examples | Windows Advanced Server 2003 implements Disable Services by Default with a role-based system which disables network servers by default that are not needed for the particular role specified when the operating system is installed (Microsoft, 2003). MacOS implements Disable Services by Default and provides the user with a control panel that both verifies if the server is running or not, and allows the server to be started.  Source: (Garfinkel, 2005) |
| Implementation | Defaults need to be specified so that servers are off by default, rather than on. |
| Consequences | Systems have a smaller “attack surface”, since servers are only enabled if they are needed (Howard, 2004). Users are more likely to be aware of the servers that are running. |
| Dependencies | None |
| Relationships | [Disable of Services] [Opt-in] |
| Principles | [Least Surprise] Least Common Mechanisms (Saltzer and Schroeder, 1975) |
| Guidelines | None |
| Check lists | None |
| Use cases | None |
| Tags | Disable by Default, Opt-in |
| 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.
Howard, M., 2004. Attack surface: Mitigate security risks by minimizing the code you expose to untrusted users. IMSDN Magazine.
Microsoft, 2003. Windows server 2003 security guide. Microsoft TechNet.
Saltzer, J.H., Schroeder, M.D., 1975. The protection of information in computer systems. Proceedings of the IEEE 63, 1278–1308. doi:10.1109/PROC.1975.9939