Secure Default

From The Secure Arc Wiki

Jump to: navigation, search

Contents

Assertion

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

Rationale

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

ACSI-33

  • 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.

CIP-005

  • 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

Navigation

Personal tools