SecureState Blog

Read SecureState's award winning blog.

By: Chintan Davis, Infosec Institute

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 COTS need to be customized to fit into the client environment, the rest of them only need to be configured according to the organization’s needs. In certain cases, organizations have a team of third-party software consultants working to develop a product on their behalf.

600px-Security_in_the_SDLC_ProcessIf an organization has implemented a Secure SDLC framework – they are ensuring the security of applications developed in-house; however acquisitions of software products from third-party vendors may not be secure, as their development process is not controlled by the organization. This presents a weak link in the entire security chain, as these products are subject to security vulnerabilities. This is a significant hole and needs to be plugged from an organization’s perspective and security teams need to work with the procurement team and senior management to coverVendor Security Management in detail.

Current Industry Trends:

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 solutions which may have already been procured by an organization, so we are dealing with a problem that has a retroactive effect from security perspective. Not only are we aiming to buy secure products going forward, but we also need to do something about existing unsecure products which are already procured.

In last couple of years, security issues in products are making it to the media when these vulnerabilities are discovered 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 contracts do not explicitly bind them to fixing such issues, legally an 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:

Embedding_Vendor-Flow

Procurement Process:

The procurement process will change from organization to organization. However from a high level perspective, the following activities are typical for any procurement process:

1) Clear Understanding of Business Requirements
2) Supplier Identification and Shortlisting
3) Pricing and Contract Negotiations
4) Finalization and Product Shipping

Breaking the Mold:

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, it is not an 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 Shortlisting

I’ll won’t explain every step of the procurement process in detail; however, I’ll cover enough to ensure that we don’t miss any important information. We are not interested in every single detail – like how a vendor is identified and shortlisted. However, we do care about what information we send to shortlisted vendors when providing them a formal description of a 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 should communicate with the vendors sharing an RFP (Request for Proposal) with them.

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 is a sweet point for the security team. We already have worked with the business to get detailed security information, which includes requirements that satisfy audit and meet the governing standard’s requirements. Businesses need to embed these security requirements into the RFP to ensure clear communication on each and every security requirement.

3)  Pricing and Contract Negotiations

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

Contract negotiations have detailed terms and conditions, which are studied by both organizations before entering into a deal. There are two key touch points which are of interest to the security team here – SLA (Service Level Agreement) and support terms and conditions.

1)  The Service Level Agreement, commonly referred to as an SLA, is an important document for the information security team. Getting the SLA terms to address security concerns will ensure that you as the 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 teams 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, you entered into 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 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 your organization should be done in 24 or 48 hours (depending on your comfort level) to validate whether this is a serious security issue or not.

2)  Support Terms and Conditions is one more area in which the security team should look into to ensure that the 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 algorithm to ensure that their product can be more generalized and can be deployed easily for more clients? What if you 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 noncompliance if the vendor does not provide timely support and you can’t push it legally as it is not included in the 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 you 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 your 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 supportive, we can’t do much with existing contracts. However, this is an opportunity for the security team.

You need to create an inventory of all such products with their contract start and end dates. When the contract comes up for renewal, you can use this opportunity to embed your 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 you are done with this one-time process, you have a normalized environment going forward, as your updated procurement process will address all new requirements, and you have also addressed the existing unsecure products as well by negotiating the terms and conditions.

Repeat the Process

As products come in and out of the environment, it’s critical that they are added to the list of systems that are covered by vulnerability scans, web application scans and other security assessments to ensure the company takes a proactive approach to identifying vulnerabilities or misconfigurations in these third party applications or systems on their network. Once you establish a secure procurement process and index already purchased solutions, you will have a repeatable process to ensure security is address with all third-party products.