Use of SecurITree in Sensitive Environments | Amenaza Technologies Limited

Use of SecurITree in Sensitive Environments

Amenaza's SecurITree software is currently used by a number of U.S. defense contractors and U.S. Federal Agencies for classified work. Since Amenaza is a Canadian company, it may not be clear how a customer should proceed to get approval to run SecurITree software on a classified network. There is no universally applicable answer to this question, but Amenaza can provide some direction in this regard. The following is not intended as legal guidance, but rather to suggest areas that may be investigated by customers looking to satisfy their particular requirements.

Statement by the Department of Defense on the Use of Canadian Technology

The United States of America and Canada have a unique relationship and a longstanding policy of trust on defense-related issues. A Department of Defense Instruction, originally published in 1980 and reiterated in February 2006, clarifies the Federal government's position on the use of Canadian technology in defense applications.

Source Code Review

Amenaza is willing to make source code available under a license agreement to customers with a legitimate need to know for purposes of security review and escrow. In many cases, this may satisfy concerns.

SecurITree Does Not Affect Network Operation (it is not a firewall or monitoring tool)

If further assurances are required, it may be necessary to demonstrate that SecurITree operates in accordance with government policy. A key point is that, from a network point of view, SecurITree doesn't have any active role in the processing of network data or in enforcing security policy. Architecturally, it is very similar to a desktop application such as a spreadsheet. The evaluation process for these types of applications is usually less stringent than for firewalls or encryption devices.

NIAP and NSTISSP No. 11

Many U.S. federal agencies are using the National Information Assurance Partnership (NIAP) initiative to meet security testing needs. In most situations, NIAP encourages the use of the Common Criteria (CC) to evaluate IT security products. NSTISSP No. 11 discusses the policy governing the acquisition of trusted products (see http://www.niap-ccevs.org/nstissp11_factsheet.pdf). The NSTISSP requires that Information Assurance products, such as firewalls, cryptographic modules and intrusion detection systems pass a Common Criteria evaluation or a Federal Information Processing Standards (FIPS) 140-1/2 validation as appropriate. The NSTISSP also states that Information Assurance Enabled products (products like operating systems and data bases which use IT security, but for which computer security is not the main focus) are also included in the requirement. Quoting from the NSTISSP document we read:

In this context, it is important that COTS IA and IA-enabled IT products acquired by the U.S. Government Departments and Agencies be subject to a standardized evaluation process that will provide some validation that these products perform as intended. ... The objective of NSTISSP #11 is to ensure that COTS IA and IA-enabled IT products acquired by the U.S. Government for use in national security systems perform as intended by their respective manufacturers, or satisfy the security requirements of the intended user.

However, SecurITree is not an IA/ IA-enabled product, i.e., SecurITree does not provide any type of security service. It models the behavior of adversaries against systems, but it does not protect the target in any way. In fact, the system being modeled may not have any information security components at all.

NSTISSP #11 applies to all IA and IA-enabled IT products in a given solution. Whether a component is considered an IA/IA-enabled IT component depends heavily on the nature of the architecture in which it is being placed. If the component is not "cognizant" of the security policy and has no security policy enforcement responsibilities (i.e. it is not required to make policy enforcement decisions or implement a security feature), it is not considered to be an IA/IA-enabled IT component and hence will not need to be validated.

Finally, it is Amenaza's understanding that no Common Criteria specification exists for attack tree modeling software. This is probably not an oversight since Common Criteria is intended for the certification of products that enforce security policy. Since SecurITree does not perform this function there is no Common Criteria specification that can be used to evaluate it.

If you have specific concerns in this area, please contact Amenaza Technologies Limited for further information.