Secure - By Default

Secure - By Default

Copyright 1991-2007, Sun Microsystems, Inc

Policy Synopsis

 Secure by Default (SBD) is an initiative at Sun to fortify the install-time security posture of our products by default. In this context, "default" refers to the customer perception of the product's capabilities and exposures during and immediately after installation regardless of the installation options expressed. Note: in some cases offering unsafe installation options might be desired by a product (e.g. to allow for a backward compatible install image.) Such unsafe options are discouraged and should be easy to recognize by the administrator and include a warning.

 SBD includes all aspects of the customer's experience with Sun's products starting from the distribution of installation tools, executable components (e.g. programs, libraries and scripts) and their original (unmodified) configuration through the operation of the installation tool and finally to the resulting system with the product installed. Customers are asking Sun to assure all of our products are resilient to hostile attack throughout this process. This enables the customer to install Sun's products on systems connected to a hostile network with the confidence that the system remains protected and is ready to be personalized to deliver the desired services.

Contents

• Applicability
• Background
• BestPractice
• Advice

Overview

Applicability

Background

 The SBD initiative grew out of discussions with many customers who strongly challenged Sun to make our products resilient to attacks throughout the product lifecycle. These customers emphasized their disappointment that many of Sun's products install with unnecessary exposures to attack and require the customer to develop or follow Sun best practices on how to secure the system prior to being safely connected on a (hostile) network. This challenge has also been given to the industry by the President's Strategy to Secure Cyberspace and the resulting recommendations by the National Cybersecurity Partnership's Technical Standards and Common Criteria Task Force.
 Even worse, many customers feel they need to pay for professional services to adequately protect their systems and in some cases this has led to questions about whether the protected configuration is still supported by Sun. Clearly these situations affect the customer's security perception of Sun and drives up their total cost (and time) of initial deployment thus creating a competitive opportunity for other vendors. Several competitors have already shipped SBD features including: HP (using Bastille), Microsoft (XP SP2), RedHat 9's new installation tool.

BestPractice

• Applies to All projects
• Authority SAC
• Effective September 15, 2006
• Policy 
   The Security SWG will offer several SBD-oriented policies to help guide the understanding and compliance with this initiative. In order for a product to be considered SBD compliant it must conform to each of the SWG policies: Install-Time Security, and Validated Product Distribution. The scope of these policies is described below:
  • Install-Time Security
     This policy covers the resilience to network-based attacks against the installation tool and installed product as covered in the Installation Tool and Product Hardening areas. It also covers the preventative and diagnosability aspects of locally originated attacks against the installation tool and installed product as discussed in the Installation Tool and Product Hardening areas.
  • Validated Product Distribution (TBD)
     This policy defines the desired properties associated with the validation of a product's contents such as its executable components and their configuration. This validation includes the components used to install the product as described in the Validated Product Distribution area.

Advice

 SBD focuses on the early stages of the product deployment lifecycle: distribution, installation and the resulting product configuration. The later stages of personalizing and deploying the product are covered by the Secure in Deployment initiative which is outside the scope of this document.

 In order for a product to be SBD compliant, it needs to offer installation options which meet the policies for all of the following areas:

• Validated Product Distribution - a mechanism enabling the administrator to assure that the installation tool and the portions of a product's contents that affect its use (e.g. executable components and their unmodified default configurations) are authentic as intended by the product creators.
   For example, a product could include digital signatures being associated with each executable component and its configuration so the installation tool (or administrator) can verify their authenticity prior to use. These digital signatures could be included within the product or be remotely accessible over a secured connection.
•  Installation Tool Hardening - during the installation of the product, the installation tool and the system itself is resilient to local and over the network attacks.
   For example, the installation tool could employ cryptographic mechanisms to protect all networking used and expose minimal to no direct access to privileged software performing the installation.
•  Product Hardening  - the resulting product running on the system after installation is automatically security hardened to be resilient to local and network-based attack.
   For example, in order to properly harden many products, the installation tool might need to understand the installer's preferences for how tightly the product should be restricted and its eventual role. This information enables the installation tool to minimize the security risk to the product by installing the necessary software and pre-configuring and executing only those services dictated by the administrator.