What’s changed since NDcPP v1.0?

[March 12, 2019 Update] NDcPPv2.1 has been formally endorsed by NIAP.

There are 41 products listed on the NIAP PCL that are compliant with the collaborative Protection Profile for Network Devices (NDcPP) v1.0.  These PCL listings will all expire within the next year or so. What can these vendors expect when updating their certifications from NDcPP v1.0 to NDcPP v2.0e? In this post, we examine the changes that have occurred to the NDcPP to help answer this question.

First, why NDcPPv2.0e and not NDcPPv2.1? Because NIAP have not yet approved v2.1 and we have no insight into when this might happen.  To see the differences between v2.0e and v2.1, see Notable NDcPPv2.1 Changes (from v2.0e).

So, here are the main differences between NDcPPv1.0 and NDcPPv2.0e:

• Support for Distributed TOEs added (watch this space for a post about distributed TOEs) – this shouldn’t impact vendors who are simply re-evaluating new versions of their products (unless adding a distributed component)
• If using NTP, this must be tunnelled over a secure channel, which is quite impractical (per NIAP TD 321). Time can still be set manually. See our related blog post: NIAP TD0321: Protection of NTP communications
• Discontinuous changes to time must be logged even if this is because of NTP
• FIA_AFL.1 added – detect when x number of admin authentication attempts have failed and lock the account. Lockouts must also be logged. Further, this kind of mechanism cannot apply to the local console.
• Details of how published hashes can be used for trusted update have been added – something to look at if you rely on a published hash (see Application Note 31).
• Explicit support for DTLS added in the form of FCS_DTLS – you’ll want to look at this if you rely on DTLS for syslog for example.
• IPsec – support for additional ciphers added, requirements added regarding reference identifiers.
• SSH – various tweaks to these requirements, notably re-key thresholds – see our related blog post: SSH Rekey Limits with OpenSSH.   
• TLS – various changes here; notably, explicit rejection of disallowed SSL/TLS versions, changes to supported ciphers and more explicit requirements for setting / checking reference identifiers.
• X.590 – lots of changes making requirements more explicit (typically dragged in if you are relying on TLS Client, i.e. for LDAPS or Syslog over TLS)
• Conventions for identifying SFR iterations has changed along with some SFR editorials – Security Targets will have to be updated to accommodate.

Then of course, you’ll want to ensure you comply with all of the applicable NIAP Technical Decisions for NDcPPv2.0e:

• TD0343  NIT Technical Decision for Updating FCS_IPSEC_EXT.1.14 Tests
• TD0342 NIT Technical Decision for TLS and DTLS Server Tests
• TD0341 NIT Technical Decision for TLS wildcard checking
• TD0340 NIT Technical Decision for Handling of the basicConstraints extension in CA and leaf certificates
• TD0339 NIT Technical Decision for Making password-based authentication optional in FCS_SSHS_EXT.1.2
• TD0338 NIT Technical Decision for Access Banner Verification
• TD0337 NIT Technical Decision for Selections in FCS_SSH*_EXT.1.6
• TD0336 NIT Technical Decision for Audit requirements for FCS_SSH*_EXT.1.8
• TD0335 NIT Technical Decision for FCS_DTLS Mandatory Cipher Suites
• TD0334 NIT Technical Decision for Testing SSH when password-based authentication is not supported
• TD0333 NIT Technical Decision for Applicability of FIA_X509_EXT.3
• TD0324 NIT Technical Decision for Correction of section numbers in SD Table 1
• TD0323 NIT Technical Decision for DTLS server testing – Empty Certificate Authorities list
• TD0322 NIT Technical Decision for TLS server testing – Empty Certificate Authorities list
• TD0321 Protection of NTP communications
• TD0291 NIT technical decision for DH14 and FCS_CKM.1
• TD0290 NIT technical decision for physical interruption of trusted path/channel.
• TD0289 NIT technical decision for FCS_TLSC_EXT.x.1 Test 5e
• TD0281 NIT Technical Decision for Testing both thresholds for SSH rekey
• TD0259 NIT Technical Decision for Support for X509 ssh rsa authentication IAW RFC 6187
• TD0257 NIT Technical Decision for Updating FCS_DTLSC_EXT.x.2/FCS_TLSC_EXT.x.2 Tests 1-4
• TD0256 NIT Technical Decision for Handling of TLS connections with and without mutual authentication
• TD0228 NIT Technical Decision for CA certificates – basicConstraints validation

Your CAVP certificates may also need to be refreshed.

In summary, if a product complies with NDcPPv1.0 it doesn’t necessarily follow that it will also comply with NDcPPv2.0e.  The best approach is to undertake a Functional Gap Assessment (FGA) against the new requirements to ensure that your product is certification ready.

At Lightship, we use our Greenlight Common Criteria test automation platform to perform FGA testing in a fraction of the time that it would take manually. By leveraging our flexible and intelligent combinatorial test generation engine, we can create a complete test plan and start executing testing on day one. This is a game changer that flips the test activity from the end of an evaluation to the start of the project – during the evaluation preparation phase.

Here are the track changes version of the NDcPP so you can see the changes for yourself. Enjoy!