Embedding Security in Procurement Process & Vendor Contracts – Part 2

April 15, 2013 by

arD3n7

Background:

In the previous article, we've covered how to implement security in procurement process and vendor contracts. There are 3 different aspects to managing vendors:

We have covered Product procurement & Product support in the previous article; however, this leaves one more important aspect –Services. Also called Managed Services by some vendor organizations, this is an equally important aspect, but the approach to vendor security management, when it comes to services, is slightly different and there may be additional action items on our end, from an organization's perspective.

Objective:

The aim of this article is to help readers understand how to ensure proper security when consuming vendor services. Security Management in Products procured is straightforward as we discussed previously, but since service is a continuous activity, proper care needs to be taken.

What is a Service?

A service is an activity a vendor performs on behalf of the organization which has hired it. It could be developing a source code, providing consultancy on a certain area with the help of an SME (Subject Matter Expert), managing the network on behalf of the organization, etc. A service is pretty much anything that a vendor could deliver with the help of human resources for its clients.

Approach to Managing Vendor Security:

We'll cover a sample approach that can be used by organizations to manage security in services provided by a vendor. It should be noted that the following approach be considered a sample only since every organization is different. Each organization will have their own processes and structures and the approach will change based on the organization.

Following is a brief overview of the steps involved in the entire process:

1. Background Security Check
2. Formal Contract Signing
3. Signing NDA (Non Disclosure Agreements)
4. Training
5. Formal Reporting Structure
6. Random Security Audits for Vendors

Following is a pictorial representation of the approach:

We'll cover each one of these steps in detail in the following sections.

For the sake of uniformity, I'll use software development as an example service and continue the article based on it. We'll leave out the steps like identification of vendor and negotiation of cost as they are not much of a concern to us. We'll instead focus only on major areas which we can fine-tune from a security perspective.

1. Background Security Check
   

   The organization should introduce a background security checking program by working with the HR department if such a program is not already in place. This is a critical piece of the entire keychain. As said, security is only as good as the weakest link in the entire chain – hence we may not want to miss out on any touch points as far as security is concerned.

   It is a good idea not to limit this program only to contractors and have it span across every employee of the organization as well. However, for this article, we'll limit our scope only to vendors or contractors.

   Normally, an organization first awards a service contract (in our case, software development). Once the contract is given, the next step is to get the the vendor's development team onboard to work in the organization's premise or any other location as discussed in the contract.

   Background Security Check is performed before the team joins the organization and starts working on the project. Each and every contract employees' credentials should be verified to ensure that there is no fraud from faking credentials or experience. This is normally done by calling the HR department of each organization for which the employee has worked for and checking his or her job responsibilities and the duration for which they have worked there. Next step is to check their academic credentials from a background check perspective. This can be verified by contacting the university or college in question and verifying whether the employee indeed studied there or not.

   Next thing is to check the employee's criminal conduct. The organization should check if the employee has any criminal background or has been involved in any illegal activity, or if there are any legal cases pending against the contractor. This will in a way will not only provide a kind of character reference check for an individual, but also look into the criminal history an individual may have, if any.

   We'll not cover each and every possible background security check as that may run into pages, however the point is to highlight the importance of this activity. Background Security Checks can change from organization to organization.

2. Formal Contract Signing
   

   A contract is an agreement between two (or more) different parties and this contract is prepared by keeping the legal team in the loop and is enforceable by law if the need arises. Most contracts signed for "services" also have something known as a Service Level Agreement or SLA, a part of the service contract which defines the objective time line to deliver a service. An example could be troubleshooting of network problems in a maximum of 48 hours or releasing a hot fix for security vulnerability in 3 working days, etc. In a nutshell, an SLA contains a common understanding between both vendor and organization about the service, their responsibilities, the time to address certain activities critical to the business and similar other important activities.

   Contract signing and background verification – both these activities can be done in parallel as both activities will take time. The legal team from the Vendor Organization will also review the contract and if any changes are required prior to signing, the legal team can incorporate these changes based on management's approval. Once all confusions are cleared and both parties agree upon a common ground, the contract is prepared and both parties can sign the same.

   In our case, both parties will sign the contract which outsources software development to a vendor. The vendor's team will be working at our organization's premise and developing the software as per the specifications and requirements provided by the business.

3. Signing Non Disclosure Agreements
   

   A Non Disclosure Agreement (NDA), sometimes also referred to as a Confidentiality Agreement, is a legal contract between a service provider (vendor) and service consumer (our organization) which clearly identifies what data can be shared and what information is restricted. Normally, sharing data classified as public can be shared as it doesn't disclose any organization's proprietary data, while, on the other hand, data classified as sensitive can't be shared.

   This document clearly notes these expectations in legal language which could hold in a court of law should the agreement be breached during the course of the contract from a vendor's end.

   Service consumer should ensure that every vendor personnel (will be referred to as contractors going forward) signs the NDA before they start working on the software development project. This step is very important and skipping or omitting it intentionally or due to oversight can be disastrous for any service consumer, as the contractor can copy and even carry the entire application's source code without any hassle as no one can challenge them legally should the NDA not be signed.

4. Training
   

   Once contractors join the organization, provided background verification check is completed successfully and all legal documents are signed, every contractor should go through a training program. This training should introduce contractors and make them aware of important security policies and procedures that need to be adhered to by every person working for the organization – be it employee or contractor. In case these policies and procedures are violated, appropriate actions should be taken. This sometimes can be as extreme as termination of employment for employees or cancellation of contract for vendors or contractors.

   Training programs are important as they ensure that contractors are formally aware of company guidelines and post training, should they violate policies and procedures, it is most likely because the contractor intentionally chose to do so and not because he or she did not have the required knowledge. Once formally attended, non-repudiation can't be executed by the vendor.

5. Formal Reporting Structure
   

   Every contractor should be responsible for delivering time bound and good quality output for tasks assigned to him or her and someone from the service consumer's end (organization in our case). Normally, contractors report to application owners as they are the folks who decide on who will deliver their applications and choose the team. Hence, they should be accountable for ensuring that these contractors do their job.

   Having a formal reporting structure will ensure that an organization's norms are followed and that newly joined contractors blend in well into the organization's structure. Formal communication and even concerns can be routed to these contractors via their reporting managers.

6. Random Audits for Vendors
   

   Last but not the least, at any point of time, an organization may have multiple vendor teams delivering services to different business units, hence it makes sense to have random audits on these contractors.

   

   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

   These audits will ensure that all vendors are adhering to all applicable compliances. If there is any non-compliance (NC) identified, corrective actions can be taken to fix the same. Regular dashboards should be published by the audit team in a centralized location which provides a summary of audit for management reference.

   If repetitive offenders who contribute towards Non-Compliance are identified, the same should be taken on a serious note and, depending on organization policy and such, a contractor could be removed from the project team if they don't fall in line after warnings.