Welcome to the Acumen Security Blog

Vulnerability Analysis and Common Criteria

With the advent of collaborative Protection Profiles (e.g., the NDcPP), a greater emphasis has been given to the vulnerability analysis requirements required as part of a product evaluation. Vulnerability analysis is a subset of risk management that involves looking at the system elements and layout and their failure modes based on a given set of threats. The vulnerability assessment answers the basic question, what can go wrong should the system be exposed to threats and hazards of concern?
Acumen sincerely believes that vulnerability analysis is a critical part of the certification process and a step forwards towards making sure that the product is built as per the best security standards and practices. The process usually starts with initial reconnaissance (Identifying the system components e.g.: software versions running on the system, Discover open ports and access points, Fingerprint the operating system etc.) and hence moving towards finding vulnerabilities and finally to exploitation.
We interpret system configuration settings by first understanding the overall architecture of the system and the role the device holds within an infrastructure. Armed with this information, we can then analyze the device configuration against industry best practices and hardening techniques. Our manual analysis strives to identify exposure and breach-response capabilities by looking at logging and alerting abilities, compensating controls, system roles, and defense best practices.
The process is usually targeted towards the following objectives –
Implementation of existing minimum security baseline.
Does the system configuration adhere to industry standards and best practices?
Use of protocols known to be insecure.
Up to date releases and known vulnerabilities.
Does the device configuration match its specified role?
“Who, what, when, where, and why” regarding system access.
Finally towards the end of this phase, these vulnerabilities are classified as follows –
• Very High: This is a high profile vulnerability that provides a very attractive target for potential adversaries, and the level of deterrence and/or defense provided by the existing countermeasures is inadequate.
• High: This is also considered as high profile vulnerability with a crucial impact on the security of the products.
• Moderate: This is a moderate profile vulnerability that provides a potential target and/or the level of deterrence and/or defense provided by the existing countermeasures is marginally adequate.
• Low: This is not a high profile vulnerability and provides a possible target and/or the level of deterrence and/or defense provided by the existing countermeasures is adequate.

All the products evaluated against the NDcPP (and various other PPs) will need to go through this additional vulnerability analysis process ensuring much more level of confidence towards the security level of the products.

Intrusion Prevention System (IPS) Extended Package (EP) Update Published

In late January 2016 an updated version of the Intrusion Prevention System (IPS) Extended Package (EP) was released. Although the changes to the EP itself are minor, changes to its scope may make this update significant for vendors seeking accreditation.

At first glance version 2.1 of the IPS EP is nearly identical to version 2.0 which preceded it. The scope of the EP remains the same, as are the threats it addresses and its objectives. Both the required and optional Security Functional Requirements (SFRs) have not been altered, nor have there been any changes to the Assurance Activities (AAs). What has changed is the Protection Profile (PP) that the EP can be used with. Version 2.0 of the IPS EP could only be used to extended the collaborative Protection Profile for Network Devices (NDcPP), whereas version 2.1 can be applied to products going against the NDcPP or the collaborative Protection Profile for Stateful Traffic Filter Firewalls (FWcPP). Under the old version of the EP vendors did have the option of certifying their products against the FWcPP as well, but this would not have freed them from NDcPP requirements. With the changes to version 2.1 vendors can now add the IPS EPcPP (whose official short name is still PP_NDcPP_IPS_EP despite the change of applicable PPs) to a FWcPP evaluation without going against NDcPP as well.

As of today there are no products on the Product Compliant List (PCL) or officially in evaluation that go against the FWcPP or the IPS EP so the full real life implications of this change are yet to be seen. It is interesting to note that although the NDcPP and FWcPP do not support distributed TOEs the IPS EP does allow different SFRs to be enforced by distributed TOE components, as long as those components are all capable of meeting NDcPP or FWcPP requirements on their own.