Secure Default

From The Secure Arc Wiki

Jump to: navigation, search



The default settings for each component or sub-system should be the most secure settings


Security and usability are typically inversely proportional to each other. Both are important and to choose one over the other needs to be a carefully considered tradeoff between the two.

This principle states that by default, security is provided first and a reasoned and conscious decision needs to be made to relax the security of a component or sub-system in favour of usability.

Further detailed information is available on Wikipedia.

Related References

Policies & Standards

Standard of Good Practice for Information Security

  • Section CI4.2 User Authorisation
    • Issue default access privileges of ‘none’ (ie rather than ‘read’)
  • Section CB2.2.6
    • Change important security-related parameters (eg passwords) to be different from the default values set by suppliers


  • Section 3.5.27
    • Secure Programming - Agencies SHOULD ensure that software developers use secure programming practices when writing code, including: deny access by default.

ISO 17799:2005

  • Section 11.2.3 User password management
    • default vendor passwords should be altered following installation of systems or software.

NIST - sp800-61 - Computer Security Incident Handling

  • Section 3.1.2 Preventing Incidents
    • Host Security - Insecure default settings (e.g., default passwords, unsecured shares) should be changed.


  • Section R2 - Electronic Access Controls
    • These processes and mechanisms shall use an access control model that denies access by default, such that explicit access permissions must be specified.

Design Patterns


Personal tools