10 security things to agree with your supplier

You can’t get what you want, ‘till you know what you want. We need to define the requirements for security and privacy and agree them with the supplier. In most cases, what is not agreed will not be delivered. Therefor, the security requirements need to be documented and communicated clearly. How to achieve that?

First, the security requirements of the data need to be specified. Subsequently, it is important to communicate them to the supplier. They form the boundaries for the design, implementation and management of the outsourced service. This should be reflected in contracts, SLA’s, security reports, etc.

Explicitly agree all expectations you have from a third party
Figure 1. Explicitly agree all expectations you have from a third party

Tailor-made expression of security requirements

Security requirements are often bundled. Together they represent a certain level of security. A common way to determine the required security level is by means of classification of the dataset. Classification can be done on different characteristics, widely used are Availability, Confidentiality, Integrity, Accessibility and Privacy. It’s not necessary to use all of them, only take the attributes that help to make a distinction between the data sets. Classification of the supplier (based on the datasets he processes) is performed first. The result should lead to a minimum set of measures.

For many security practitioners, security is based on three core pillars: Confidentiality, Integrity and Availability – also known as the CIA triad. These work pretty well in a technical environment where information systems need to be classified in order to determine the security requirements that apply. Especially in the financial industry, the schemes for security classification based on the CIA triad are pervasive through the whole organization.

However, when talking with business owners it often turns out that these terms are meaningless to them. They have a clear understanding of which people are allowed to access which systems, but they don’t use these “security” terms for that. In addition, the three terms are too broad: they can mean something completely different in two different environments. For example, availability can be used for ‘archived for 7 years’, but also for ‘responding within 1 millisecond’. Therefor, we need to move away from the narrow CIA triad and adopt a richer and more flexible terminology. This can be found in the SABSA Business Attribute model. Business Attributes offer a flexible and powerful way of expressing the security concerns of the business owners.

Baseline

An alternative to the tailor-made expression of security requirements is the use of a security baseline. Best practices and standards help a lot her. They can be used as sources of inspiration to assemble a list of security aspects that covers the need and fits the maturity level of your own company. After all, many security requirements are generic and apply to any information system or service. Frequently used frameworks are:

Essential security aspects to agree with suppliers

Contracts usually don’t allow to agree all requirements in detail. Here it’s important to outline the security requirements, and to make references to detailed requirements where needed. In general, it makes sense to include the following security sections in contracts:

  •  1. Ownership, responsibility and liability
  •  2. Security policy
  •  3. Incident reports
  •  4. Availability
  •  5. Privacy
  •  6. Confidentiality
  •  7. Access control
  •  8. System security
  •  9. Back-up and recovery
  • 10. Right to audit

The content of each section is determined by the security classification and associated requirements. In any case, the security objective should be specified. What do you expect from the supplier? If helpful, a reference to security standards, frameworks or procedural agreements can be included.

Where to document the security arrangements?

External services vary greatly in the extent to which customer-specific adaptation is possible. In a tailor-made application, there is much room for security requirements. A one-to-may cloud service does not provide that freedom and comes with a fixed set of supply conditions. Depending on the type of supplier, security arrangements can be included in the:

  • Contract
  • Service Level Agreement (SLA)
  • Appointments and Prodecures
  • Purchasing conditions,
  • Supply conditions
  • etc.

Conclusion

Contracts with suppliers must include security sections. These contain the security objective, requirement and possibly a reference to a further elaboration. The power ratio between the supplier and the customer determines the ability to make specific appointments, and these may be spread across multiple documents. In the following blog, the control of the security of the external service will be discussed.

Next: Usage of http security headers