Page052

Security and Third Parties

Organizations are increasingly reliant upon third parties to provide significant and sometimes business-critical services. While leveraging external organizations is by no means a recent phenomenon, the criticality of the role and also the volume of services and products now typically warrant specific attention of an organization’s information security department.

Service Provider Contractual Security

Contracts are the primary control for ensuring security when dealing with third-party organizations providing services. The tremendous surge in outsourcing, especially the ongoing shift towards cloud services, has made contractual security measures much more prominent. While contractual language will vary, there are several common contracts or agreements that are used when attempting to ensure security when dealing with third-party organizations.

Minimum Security Requirements

Minimum security requirements describe the baseline security controls required for a third-party company to do business with an organization. They specify the following types of controls: patching SLAs, antivirus, complex passwords, dual-factor authentication, encryption, application whitelisting, employee training and awareness, etc.

Service Level Agreements and Service Level Requirements

A common way of ensuring security is through the use of Service Level Agreements, or SLAs. The SLA identifies key expectations that the vendor is contractually required to meet. SLAs are widely used for general performance expectations, but are increasingly leveraged for security purposes as well. SLAs primarily address availability.

Service Level Requirements describe the services to be provided by a third party. These requirements are used to design the SLA: “A service level agreement (SLA) specifies minimum performance requirements and, upon failure to meet those requirements, the level and extent of customer support that must be provided. Service level requirements are system requirements that specify the conditions upon which the SLA is based” [^14^].

Attestation

Larger providers and more discerning customers regularly look to attestation as a means of ensuring that some level of scrutiny has been applied to the organization’s security posture. Information security attestation involves having a third-party organization review the practices of the service provider and make a statement about the security posture of the organization. The goal of the service provider is to provide evidence that they should be trusted. Typically, a third party provides attestation after performing an audit of the service provider against a known baseline. However, another means of attestation that some service providers will offer is in the form of penetration test reports from assessments conducted by a third party.

Historically, the primary attestation vehicle in security has been via a SAS 70 review. However, the SAS 70 is not overtly concerned with information security. Increasingly ISO 27001 certification is sought by larger service providers for attestation purposes. See Chapter 3, Domain 2: Asset Security for additional details on ISO 27001.

The Payment Card Industry Digital Security Standard (PCI-DSS) also uses attestation: a PCI Qualified Security Assessor (QSA) may assess the security of an organization that uses credit cards. If the security meets the PCI-DSS standard, a Report of Compliance (ROC) and Attestation of Compliance (AOC) may be issued to the organization.

Right to Penetration Test/Right to Audit

Though third-party attestation is commonly being offered by vendors as a way to verify they are employing sound security practices, some organizations still would prefer to derive their own opinion as to the security of the third-party organization. The Right to Penetration Test and Right to Audit documents provide the originating organization with written approval to perform their own testing or have a trusted provider perform the assessment on their behalf. Typically, there will be limitations on what the pen testers or auditors are allowed to use or target, but these should be clearly defined in advance.

An alternative to the Right to Penetration Test/Right to Audit documents is for the service provider to present the originating organization with a third-party audit or penetration test that the service provider had performed. As stated above, these documents can also be thought of as attestation.