Network Install-Time Security

Network Install-Time Security

Copyright 1991-2006, Sun Microsystems, Inc

Policy Synopsis

Policy for network security during and as a result of product installation.

Contents

• Applicability
• Background
• Policy
• Exemptions
• Appeals

Overview

Applicability

Background

Policy

• Applies to All projects
• Authority SAC
• Effective July 1, 2005
• Policy All products must support Network Install-Time Security as defined in this policy.
• Details 
  DEFINITIONS
   An execution of a product installation is a Network-Secure Execution (NSE) if that execution at no time introduces any network vulnerabilities or exposures when the product is on a network. (Purely internal interconnects are excluded.) All accessible networks must be assumed to be actively hostile to the product.
   A product supports Network Install-Time Security if all of its installation procedures are designed such that:
  • NSE is maintained to the extent the administrator is never asked for input, and
  • each time the administrator is asked for input, at least one choice will maintain NSE, and if a default is provided, accepting the default will maintain NSE, and
  • each time the administrator is asked for input, either:
    • NSE is maintained no matter what input the administrator provides, or
    • choices that maintain NSE are clearly differentiated from those that violate NSE, or
    • the administrator is warned and asked for confirmation when a choice is made that violates NSE
       A network vulnerability or exposure is a state in a network service, not mandated by compliance to an external standard, which allows a network-based attacker to:
  • execute commands as another user,
  • access or transfer data in a manner contrary to the specified access policy for that data,
  • pose as another entity,
  • conduct a denial of service that could reasonably be prevented,
  • gather information that could lead to a compromise of the system,
  • gather information that could be considered sensitive under some reasonable customer security policy, or
  • compromise the system using a capability that behaves as intended.
     [This last definition was adapted from http://www.cve.mitre.org/about/terminology.html#Def]
    GUIDANCE
     For each network service that is created, installed, used, or depended on by the product, there are four ways to achieve NSE:

SVC1

Do not install the components that comprise the network service.

SVC2

Ensure that the network service is never enabled or automatically used by the product itself, during or as a result of installation. (There is no requirement to prevent layered products or post-install administration from enabling or using the network service.)

SVC3

Ensure that the network service is always enabled or automatically used by the product itself in a way that satisfies the minimum security requirements specified further below, both during and as a result of installation. (There is no requirement to prevent layered products or post-install administration from enabling or using the network service in ways that do not satisfy the minimum security requirements.)

SVC4

Ensure that failure to satisfy the minimum security requirements introduces no network vulnerabilities or exposures.
 The SVC1 approach is often an important option to provide in addition to one or more of the other approaches, but careful consideration should be given to its potential impact on subsequent administration of the system before making it the default. If a network service is pre-installed, such that the customer has not explicitly expressed a desire to use the service, or if the network service is installed as part of a larger suite such that customer use of the service is not a high probability, the SVC2 approach should be strongly favored as the default. If installation conveys an explicit or high probability of customer use of the network service (for example, active install of a dedicated-use product), the SVC3 approach should be favored as the default.
 For an inbound network service (one that listens for inbound communication from one or more networks), the minimum security requirements are:

IN1

Access control must be enforced for inbound communication, with a "default deny" authorization policy. That is, by default all inbound requests must be rejected, in such a way that no network vulnerabilities or exposures are introduced by any data communicated as part of that rejection.

IN2

The access control check must be made as early as possible relative to processing inbound data, to avoid or minimize content-based attacks.
 Note that authentication of the "requestor" of the inbound communication is not required to satisfy these requirements.
 For an outbound network service (one that initiates outbound communication on one or more networks), the minimum security requirements are:

OUT1

The "receiver" of the outbound communication must be authenticated in a manner that introduces no network vulnerabilities or exposures.

OUT2

Authentication of the receiver must occur prior to revealing any data that could be potentially sensitive or could lead to compromise, and must occur as early as possible relative to processing inbound data to avoid or minimize content-based attacks.

OUT3

Data integrity must be maintained on both outbound and inbound communication, and confidentiality (via encryption) must be maintained on both outbound and inbound communication for any data that could be potentially sensitive or could lead to compromise.
 Note that authentication of the receiver is not restricted to just connection-based authentication. Also note that network services are not required to use IP Security Protocol (IPsec); Kerberos, SSL/TLS, and SSH are all examples of protocols that can readily be used in ways that will satisfy the minimum security requirements.
 This policy is not intended to eliminate all possible denial of service attacks; rather, it is aimed at those denial of service attacks which can reasonably be prevented, in the layer/product that is appropriate for the task, while still remaining compliant with applicable standards. For example, layered product services are not expected to be concerned with preventing TCP SYN flooding, but services that use Java object serialization should be concerned with memory allocation and computation attacks that could be launched simply by crafting small custom byte stream sequences. Good engineering judgment will be required to determine which attacks must be dealt with.
 In both the SVC3 and SVC4 approaches, particular care must be taken to prevent information gathering activities (but note this policy is not aimed at preventing fingerprinting or similar forensic techniques from being used to infer information). Even information that might seem benign can often be considered sensitive. For example, in an inbound HTTP service, the "Server" response header typically includes product and version information that customers may reasonably consider to be sensitive; this information might be included unwittingly in all responses in the SVC4 approach, and even in rejection responses in the SVC3 approach. It is therefore critical that enabled network services be carefully evaluated for such exposures. In general, the "default deny" authorization policy (specified in requirement IN1) should be implemented by revealing as little information as possible to the requestor; in so doing, sensitive information will be excluded automatically, without actually having to determine if the information is sensitive.
 There are no auditing, logging, or non-repudiation requirements for Network Install-Time Security. Auditing and logging provide a recorded trail of events and errors that are often invaluable for security analysis and troubleshooting. Given this, it is strongly encouraged that local auditing and logging of basic network-security-relevant events also be enabled by default for any network services enabled by the installation.

Exemptions

Appeals