Understanding the Scope of NDcPP Evaluations

When first exposed to the Network Device collaborative Protection Profile (NDcPP), vendors are often surprised by the extremely narrow scope. It is critical to realize that the Protection Profile (PP) refers to an abstract “network device” with required functionality that should appear in any good network citizen. It doesn’t look to any specific vendor or technology type. Rather, the PP refers to the minimalist ideal of security-relevant functionality focused almost entirely on how security administrators interface and interact with the device.

Note: When attempting to boil a 350 page (combined PP+SD) standard to its distinct philosophy and main points, the nuances are likely to be ignored. Our intention is not to showcase every single edge case, but to provide more of an overview of the scoping an NDcPP project. Edge cases abound.

Fundamentally, the NDcPP is concerned with how a device appears to a security administrator on an IP network (the term “security administrator” implies a distinction of capabilities even though the PP, in practice, doesn’t require any such separation in roles). The NDcPP is concerned with protecting how that device accesses and uses (or provides) resources on the management plane rather than the user plane. If you have an Ethernet switch, then the switch ports are going to be primarily responsible for transporting data on a user network; if you have a storage device, your network-aware storage facilities are primarily responsible for storing user data; if you have an email gateway, a network card in the appliance will be more concerned with transporting and protecting email.  In short, the user plane is where your product performs its valuable or differentiated functionality. The mechanisms by which the overall product is configured and maintained represents the management plane. With a few exceptions (such as firmware updates) it is how administrators and their sessions are configured that constitutes the NDcPP scope.

In the figure above, a product will have some proportion of itself devoted to the ability to configure its functionality. This overall administrative functionality will naturally include elements that fall inside and outside of the mandatory NDcPP function set. Often the set of in-scope management actions is a very small subset. (Distributed solutions needing multiple components to satisfy the sum total of in-scope functional requirements have a slightly different take on how functionality is to be handled, though the philosophy remains largely the same.)

NDcPP targets have two broad categories of in-scope functional requirements:

1. Those related to the administrative user and how they and the TOE conduct themselves during an administrative session; and
2. Discrete functions that all enterprise-class, security-conscious device vendors must provide.

These functions are the result of a high-level threat-mitigation assessment that compliant targets are minimally trying to solve. The threats and their mitigations form the basic philosophy of the in-scope NDcPP functionality. This information is provided in a very readable form in the opening sections of the Network Device collaborative Protection Profile. For example, it is section 4 of v2.1 of the NDcPP.

Requirements levied on the administrative user revolve around:

• Types of available manageability interfaces;
• Login and logout (and time-out) of administrative sessions; and
• Use of credentials, password complexity, and how login failures are tracked and handled.

Functional requirements levied on the device, include:

• Local and remote auditing of in-scope functions;
• In-scope credential protection;
• Device self-testing (ie. that the operation of the device can be relied upon);
  
• Firmware updates (ie. that the integrity of the update can be relied upon);
• Origin and use of accurate time information (ie. for things like auditing, session timeouts, X.509 expiry date calculations, etc.); and
• Cryptographic properties of the underlying in-scope inbound and outbound traffic channels (for example, and not limited to, management web interfaces, SSH CLI, LDAP or syslog over TLS).

The NDcPP is somewhat viral in nature: if a management interface includes some in-scope management functionality (usually, other than session management), then it either needs to be disabled in the evaluated configuration or it has to be pulled into scope. An example of this might be if there is a REST API interface which, for whatever reason, has the ability to configure the minimum password length. If this is the case, then the entire management interface must be pulled into scope, including ensuring it is performed over a cryptographically secure channel, have proper identification and authentication, provide auditing, etc. Otherwise, the REST API must be disabled in the evaluated configuration or the specific functionality be removed from the management interface.

One constant but still surprising aspect of the NDcPP is that out-of-scope functionality simply isn’t examined even if it falls within one or more of the claimed manageability interfaces. Additionally, if out-of-scope functionality is provided within a completely distinct administrative context (eg. there is a management interface which only provides access to configure administrative information from the blue circle in the figure above), such an interface may also not be in-scope (or its scope may be substantially narrowed).

Scoping an NDcPP properly can often help limit the amount of development work needed to meet the remainder of the requirements. Lightship Security is very well versed in the NDcPP, its nuances and the minimally-compliant target functionality. Our Functional Gap Assessment (FGA) process exercises your device in an accelerated evaluation context to provide you with valuable remediation information and scoping considerations.

Talk to us today on how we can help you realize your federal sales needs and help certify your product at the speed of development.