Why Protection Profiles Matter in Common Criteria Certification

By Elevate posted 07-01-2014 08:50


Nigel Tufnel.jpg

I recently was reading a report by a well-known IT analyst firm on industry firewalls, when I was surprised at a comment the report made regarding a competitor’s recent Common Criteria certification.  The report highlighted the competitor’s recent EAL 4+ certification.  The reason I was surprised was not that the competitor had achieved an EAL 4+ certification, but instead that this well regarded analyst had bothered to include something as passe’ as an EAL 4 Common Criteria certification in their report. 

Certainly, Juniper Networks devices, including the SRX family and other devices like ScreenOS Firewalls and the LN1000 have completed EAL 4+ certifications in the past.  This was, however, when an EAL 4 certification was relevant and when there was a government requirement to do so.  This is now no longer the case. 

In the last several years, the National Information Assurance Partnership (NIAP), and the Common Criteria authorities from Canada, the UK, and Australia and New Zealand have moved away from a process that emphasized the Evaluated Assurance Level (EAL) towards a system that emphasized compliance with a pre-defined definition of security functionality called a Protection Profile (PP).  NIAP refers to this as NIAP Evolution.  The Competitor’s Common Criteria Certification that the analyst was touting was conducted at the EAL 4+ level, but against the competitor’s defined security target, which listed the security functionality the competitor chose to list, not the required security functionality contained in a standard protection profile.  The reason why this is a problem is a Common Criteria Certification with no protection profile claim only proves that the vendor’s solution does indeed provide the security functionality the vendor claims.  A security claim could be “my product uses passwords to protect user-ids”.  A vendor would not need to prove anything other than the product does indeed use passwords to protect user-IDs.  None of this of course is that useful to insure that a firewall actually does what government agencies or commercial enterprises need firewalls to do.

But what is the evaluated assurance level, and why did there become a fixation on higher evaluated assurance level certifications? The evaluated assurance level essentially defines the amount of documentation that a vendor provides to support a security claim.  At EAL 1, it might be sufficient that a validated third party lab test the security claim.  At EAL 4, a vendor might be required to provide, in addition to the lab test, product configuration documents, software functional design documents, etc all in the Common Criteria mandated format.  EAL 4+ certifications without Protection Profiles can essentially be paperwork exercises that either require an organization be very proficient in the nuances of how Common Criteria documents are prepared, or who have the resources to hire the consultants who know this. 

Since it is often too hard to compare one vendor’s security target to another vendor’s security target, there became a focus on the EAL level with the wrong perception that an EAL 4 evaluation provided an assurance of more security than an EAL 3 evaluation.  This focus on the EAL reminds me of the scene in the movie This is Spinal Tap, where Nigel Tufnel explains that his amps go to eleven.

Fortunately, several years ago, NIAP saw that this fixation on EAL was not improving security, so they started defining, with the assistance of industry, standard protection profiles that defined the minimum security functionality that network devices should provide.  One of the first profiles developed was the Network Device Protection Profile (NDPP).  This profile is appropriate for routers, layer 3 switches, and serves as a baseline that can be extended for security devices like firewalls.  Next, NIAP introduced the Stateful Traffic Filter Firewall Extended Package.  This protection profile is called an Extended Package (EP) because it is meant to be applied in addition to the Network Device Protection Profile.  Current US Government requirements specify that a firewall should be certified against the NDPP and the Stateful Traffic Filter Firewall EP.  Juniper Networks SRX firewalls completed Common Criteria Certification in 2013 against the NDPP and the Stateful Traffic Filter Firewall EP.  Recently, NIAP added the SRX to the NIAP Product Compliant List.  The competitor, mentioned by the analyst, is not on the NIAP Product Compliant List, since it hasn’t met the requirements to be listed.  The competitor’s recently celebrated EAL 4+ certification is Much Ado About Nothing.




07-13-2014 18:32

Hi Bill, 


Going through the actual certification document for the SRX raises a question about Non-evaluated Functionality and Services. 

Several functions including external syslog, FTP, SNMP and J-Web were not tested "violates the Trusted Path requirement Set". 

Can you further explain what this is means?




07-02-2014 07:01

Dear Concerned Fan,

Thanks for taking the time to read the blog and especially for commenting.  Your point is well taken that not all Juniper Networks products are on the NIAP list.  Juniper is working to expand our presence.  Nevertheless, I think we have reasonably broad coverage in our core products and this coverage will expand with time.

Let me recount what products are on the NIAP PCL today-

Routing- M-series, MX-series, T-series with Junos 12.1 software

Switching- EX-series with Junos 12.1 software

Security- SRX-series with Junos 12.1X44 software


Now let me highlight the current Common Criteria certifications which are in process and which Juniper expects the certifications will be added to the NIAP PCL at the conclusion of the certification.


M-series, MX-series, T-series, EX-series, QFX-series, and PTX-series with Junos 13.3- This evaluation is with the NIAP Protection Profile for Network Devices (NDPP).  This certification is being conducted in Canada.  This certification expands coverage to PTX and QFX which were not previously certified.


The SRX-series is being recertified with Junos 12.1X46 in Australia.  This evaluation also includes the LN2600.  The evaluation includes the NDPP plus the Stateful Traffic Filter Firewall Extended Package, plus new for 12.1X46, the NIAP VPN Gateway Extended package


The Junos Pulse Access Control Service with UAC 5.0 is being certified in Australia.  This includes our IC6500FIPS and MAG-series Network Access Control (NAC) appliances. This evaluation is using the NDPP.


The Junos Pulse Secure Access Service with SA 8.0 is also being certified in Australia.  This certification includes our SA6500FIPS (also our SA4500FIPS) appliances as well as MAG appliances.  This evaluation is also using the NDPP.

So the current core coverage of M, MX, T, EX, and SRX is expanding to include PTX, QFX, LN2600, and our UAC and SA platforms and the SRX certification is expanding to include the VPN Gateway EP.


This is still not the entire Juniper Networks portfolio, but it is fairly comprehensive of our core routing, switching, and security products.  Hopefully in the future, we will expand this list even further.

07-02-2014 01:58

While i agree with the gist of the article, there are so many Juniper products missing from the NIAP list I'm not sire I'd be calling my competitors out on this one.