Page392

Assessing the Security Impact of Acquired Software

We would like to believe that we can trust vendor claims regarding a product’s capabilities. Vendor claims should be taken as marketing until proven to be true. Don’t rely simply on vendor’s claims even regarding basic capabilities.

An important point is to gather requirements before reviewing products. If requirements are defined after products are reviewed, vendors might be able to convince the organization that it has specific needs that only their product can fill. Don’t let products or marketing determine what the organization “needs” in a product.

Commercial Off-the-Shelf (COTS) Software

Vendor claims are more readily verifiable for Commercial Off-the-Shelf (COTS) Software. With COTS, perform a bake-off to compare products that already meet requirements. Don’t rely on product roadmaps to become reality. A particularly important security requirement is to look for integration with existing infrastructure and security products. While best-of-breed point products might be the organization’s general preference, recognize that an additional administrative console, with additional user provisioning, will add to the operational costs of the product. Consider the TCO of the product not just the capital expense and annual maintenance costs.

Vendors’ claims are more readily verifiable with COTS software as the product can be evaluated to determine whether it provides the stated capabilities.

Third-party research and analysis organizations provide assessments of various players in a space, which can provide basic (albeit potentially biased) comparisons of products without requiring extensive in-house testing.

Customers of the vendor can often be contacted. Of course, if those contacts are provided by the vendor themselves, then be cautious with accepting claims. A better approach would be to find someone on your own that is using the product and query them concerning Pros/Cons and Likes/Dislikes.

Some questions/concerns for COTS: What happens if the vendor goes out of business? What happens if a critical feature is missing? How easy is it to find in-house or third-party support for the vendor’s products?

Custom-Developed Third-Party Products

An alternative to COTS is to employ custom-developed applications. These custom-developed third-party applications provide both additional risks and potential benefits beyond COTS. Contractual language and Service Level Agreements (SLAs) are vital when dealing with third-party development shops. Never assume that security will be a consideration in the development of the product unless they are contractually obligated to provide security capabilities.

Basic security requirements should be discussed in advance of signing the contracts and crafting the SLAs to ensure that the vendor expects to be able to deliver those capabilities. Much like COTS, key questions include: What happens if the vendor goes out of business? What happens if a critical feature is missing? How easy is it to find in-house or third-party support for the vendor’s products?