Embedding Security in Procurement Process and Vendor Contracts

Background:

Every organization has a procurement process. Some of the software products acquired by an organization are COTS (Commercial off The Shelf) Solutions. These products are not built or developed in house by the organization. While some of these products need to be customized to fit into the client environment, rest of them only need to be configured as per the organization's need to ensure that they function as per business requirements and expectations. In certain cases organizations have a team of third party software consultants working to develop a product on their behalf.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

If an organization has implemented a Secure SDLC framework – they are ensuring a security of application developed by them, however acquisitions of software products from third party vendors need not be necessarily secure – as their development process is not controlled by our organization. This presents us a weak link in the entire security chain as these products, which are acquired from third party vendors – if they turn out to be insecure - are subject to security vulnerabilities. This is a significant hole and needs to be plugged from an organization's perspective.

Objective:

The aim of this article is to cover Vendor Security Management in detail. To implement blanket security, this hole needs to be addressed. We need to work with the Procurement team and Senior Management to plug this. The approach to securing Open Source products deployed by an organization is out of scope for this article.

Problem Statement and Current Industry Trend:

When an organization has procured a product, it does not have control over third party vendor processes. Hence the security of procured product is not guaranteed. There may be many such solutions which may have already been procured by an organization. So we are dealing with a problem which has a retro effect from security perspective. Not only are we aiming to buy secure products going forward, but we also need to do something about existing non-secure products which are already procured.

In last couple of years, security issues in products are making it to the media when these vulnerabilities are found and start getting exploited. Such news headlines push the vendors to fix these issues and release patches to secure their customers from getting exploited. However, this is still limited to large organizations. If the vendor is an SME (Small & Medium Enterprise), they still may not have such a mature process to deal with security issues, and thus if our contracts do not explicitly bind them for fixing such issues, legally our organization can do little to push them to do so.

Following is a graphic of current practice or trend followed by the industry for fixing security issues found in products:

Procurement Process:

The procurement process will change from organization to organization. However from a high level perspective, following activities will be a part of any procurement process:

1. Clear Understanding of Business Requirements
2. Supplier Identification and Short-listing
3. Pricing and Contract Negotiations
4. Finalization and Product Shipping

Solution:

The best way to solve our problem is by embedding security into the procurement process.While we can continue with the "go to market and patch later" strategy – which is a current market trend, itis not the effective way to fix issues.

Let's go through the above process step by step and understand what we can do to improve security of the organization.

1. Clear Understanding of Business Requirements
   

   The procurement process should be modified to mandate the inclusion of security requirements as a part of gathering business requirements. This step is not as easy as it sounds, though. Security requirements could be as simple as having an application which supports strong authentication, or it could push the business to key in a list of complex security requirements which might include not only security requirements from a business perspective, but also include audit requirements to comply with governing standards like SOX, HIPAA, PCI DSS etc. Deriving security requirements is in itself a structured process.

   This step is very important because it is the base. As we move forward into next phases of Procurement Lifecycle, we'll need the data we have accumulated in this stage.

2. Supplier Identification and Short-listing
   

   I'll not explain every step of the procurement process in detail; however, I'll cover enough to ensure that we don't miss out any important information. We are not interested in every single detail – like how a vendor is identified and shortlisted.However we do care what we communicate with shortlisted vendors when provide them a formal description of company's requirements.

   In this stage, organizations shortlist vendors who deal in the software product which a company wants to buy. Once vendors are shortlisted, the company will communicate with the vendors sharing an RFP (Request for Proposal) with them.

   According to Wikipedia – an RFP or Request for Proposal is defined as follows:

   "A request for proposal (RFP) is a solicitation made, often through a bidding process, by an agency or company interested in procurement of a commodity, service or valuable asset, to potential suppliers to submit business proposals."
   

   The RFP also contains detailed business requirements to ensure that both buyer and seller are on the same page and the seller bids after going through all the business requirements. This a sweet point for security team. We already have worked with the business to get detailed security requirements, which also includes requirements that satisfy audit requirements to meet the governing standard's requirements. We need to embed these security requirements into RFP itself to ensure a clear communication from our end on each and every security requirement.

3. Pricing and Contract Negotiations
   

   This is one more area where we should embed security to meet organization's security expectations.Pricing is not a concern for the security team. So, we'll not dive into the details of how procurement team negotiates price and arrive at a final figure with applicable vendors. However, we are concerned about contract negotiations piece of this step.

   Contract Negotiations have detailed terms and conditions which are studied by both the organizations before entering into a deal. There are 2 key touch points which are of interest to the security team here – SLA and Support Terms and Conditions.

   1. The Service Level Agreement, commonly referred to as an SLA, is an important piece of document of interest to the information security team.Getting the SLA terms to address our security concerns will ensure that we as customer bind the product to provide service during a pre-decided period for smooth functioning of business. Depending on the vendor, there can be different levels of SLAs (e.g. Gold, Platinum etc.). We are not interested in all details about the SLA; however the point that readers should note is that the SLA is one touch point which Security Team should not miss. A comprehensive discussion with management should be done before finalizing the SLA with concerned Vendor.The following section covers one example how an SLA can impact our organization's overall security.

   Example:
   

   Let's say when finalizing the SLA, we entered an agreement with the vendor that any security issue found either by an external security researcher (published publically and noticed by our organization or reported by the researcher to our organization), or our internal security team, needs to be fixed in 15 working days if the issue is critical in nature.This clause can be a game changer when critical security issues are identified in the procured product as the vendor is legally bound to release a hot fix or a security patch for our organization – irrespective of when a patch for rest of the customers is released.

   Fine-tuning of this clause is further possible by associating deadlines with each and every step associated in the entire process. For example, analysis of the security issue reported by our organization should be done in 24 or 48 hours (depending on our comfort level) to validate whether this is a serious security issue or not.

   1. Support Terms and Conditions is one more area in which the security team should look into to ensure that our organization is not missing support from a security perspective. What if a newer version of compliance standards is published which has some additional requirements? Or, what if the vendor downgrades from a more secure encryption algorithm to a less secure encryption algorithm to ensure that their product can be more generalized and can be deployed easily for more clients? What if we missed a security requirement during the analysis phase – let's say – a federal legal requirement!!This can be a big risk as it can cause non-compliance if our vendor does not provide timely support and we can't push it legally as it is not included in our support terms and conditions.There can be many such things which need to be thought through and hence it makes the terms and conditions an important piece that we may want to address from security perspective.
4. Finalization and Product Shipping:
   

   This step deals with finalizing the deal and formally closing the entire procurement process for a particular product.It also ensures that a product shipped by the vendor is received by our organization.

   The security team does not have much of a role to play in this step. It deals more with formalizing final contracts and signing of the same, which will be tracked and followed by procurement team until closure

   Security Issues that may arise in already procured products:
   

   While we have pretty much covered everything that we need to worry about when entering into new product procurement, this does not address our problem with existing products. If the vendor is not very supporting, we can't do much with existing contracts.However,this is an opportunity for security team.

   We need to create an inventory of all such products with their contract start and end dates. When the contract comes up for renewal, we can use this opportunity to embed our security requirements and negotiate the terms and conditions for smooth handling of security issues going forward. The security team should track all such products and take them to closure.

   Once we are done with this one-time process, we have a normalized environment going forward as our updated procurement process will address all new requirements, and we have also addressed the existing insecure products as well by negotiating the terms and conditions.

   References:
   

   

   http://en.wikipedia.org/wiki/Request_for_proposal

   http://en.wikipedia.org/wiki/Procurement