Legally blond: why you do not need a 50 page security schedule

As business increasingly moves to purchasing IT as a utility from the  cloud, and more IT is outsourced and purchased as a service, there is a corresponding increase (perceived or actual) in risks relating to supplier security. A security incident at an outsourced provider and the concerns over IT being “out of my control” is a worry for many companies and maybe holding them back from realising the cost and scalability benefits on offer.  Having security clauses in a legally binding contract is one of the main mitigations for this risk. However I believe most companies either ignore security completely in the contracting process, or go too far the other way with massive security schedule that attempts to cover every possible contingency. This is an attempt to present a risk based middle path.
Value of a contract

As my lawyer told me as I was obsessing over the contract for outsourcing the development for my start-up, “it is just a piece of paper”. I thought this was a good reality check because for all the money you are paying internal or external legal and risk folk and your time invested reviewing contracts (espeically if you do not have a good master template and review each individual one), a contract is just a piece of paper. If someone is really out to get you, it is not worth the paper it is written on – especially for a small business.

This is primarily because if the other party breaches the contract you have to take some action (e.g. arbitration or in a court of law). In addition, even if a judgement is awarded in your favour you will still have to fight tooth and nail to get your money, whether that is finding the assets of a small company that has just declared bankruptcy or fighting the lawyers, appeals, countersuits and delaying tactics of larger companies. If there is offshore parties or global business involved as is often the case these days, the difficulties are magnified – even if you had the forethought to include the single applicable jurisdiction in your contract. All of this not only costs you money but also takes time and focus away from running the business and only benefits the lawyers on both sides.

So keep this in mind when you are obsessing over the security clauses in your contract, and when everyone that reviews it feels the need to “add value”. Even if there is a breech, is it going to come down to clause 149 in your contract or more likely the general negligence or breach of service levels? The best incentives to prevent a security breach are actually business ones: consider that it is generally in the supplier (even large cloud providers) interest to protect their brand by securing your systems and information - they will potentially loose far more than you if there is bad publicity of even a small incident or near miss. Keeping you happy and secure is in their short and long term interests to retain and expand their business. Cloud providers espeically should be able to leverage economies of scale to do security more effectively and efficiently than you.

That said, I believe that having security clauses in a contract can provide some benefit in the following ways:

Prior to contract – preventative measure – this is the key, being that old adage an ounce of prevention is worth a pound of cure. Security clauses should provide a clear set of requirements that just like the functional and non functional requirements for the project, detail exactly what you expect the supplier to do to protect your confidentiality, integrity and availability of your information and the systems and services provided against directed and malicious attacks.

This is strong preventative control as it makes it crystal clear to the supplier what your requirements are for security, if they are not happy with it they can either walk away or increase the price upfront which you can agree to or not. Too often in the security industry we are purposefully vague with statements such as “comply with best practice” or “industry standards”, my opinion is that it is far better to take a risk but draw a line in the sand. You can and should always review at contract renewal anyway to allow a chance to update requirements to current standards.

During the contract – a way to measure and provide penalties and incentives. If you read my article on metrics, you will understand the importance I place on being able to measure performance. Probably the most important security clauses you will have in the contract are not the clauses at all but rather the metrics on how you will measure and monitor the supplier’s security posture. I will not list more metrics because those in the article linked above are just as effectively for external parties as your internal IT (in fact if you use the same it is even better because you can use competition as an incentive to increase performance). To keep them honest you should also insist on still having the metrics collection and reporting automated and also include a statement on their accuracy in the independent audit.

The most important part relative to security in contracting is that when the metrics go red and amber it is linked to defined penalties (most likely service credits and the option of contract termination for red). The weightings of the measures should make sense relative to the importance of security to the contract e.g. if it is credit card or medical data it should be at least as important as availability and performance measures such as 99.95% uptime or 4 hour RTO e.g. 10-20% weighting. Defined actions and time periods to remediate must also be in place. Do not say that it is too hard to define this at contract time – beg, borrow and steal, it is better to have something that is 80% there rather than nothing or an informal agreement to define it later. Remediation must also be at the suppliers cost (key point). But no stick is effective without a carrot, therefore also link the green measures to bonus payments and honour them – make sure these are the top end of the green rather than the the start or middle e.g. 100% of servers patched to current security patch levels measured each month.

Do not think that because you receive an independent audit report every year you can skimp on the metrics, a set of specific, measurable metrics that are automatically collected and reported directly to you, will provide you with a lot more accurate picture of the security situation of your supplier in a lot more timely fashion than an annual audit report.

Corrective and punitive – having some form of potential recourse is better than nothing!

Risk based security clauses

This can be a bit of a hit or miss – from the perspective of the security expert it is very effective in that the required security clauses are matched to the risk of the supplier. However in practice it is not favoured by the lawyers nor the sourcing staff. This is because while security is the most important thing to you (or at least what you are a paid to do), the security schedule is one of at least ten major things they need to include in the contract. From their perspective they would prefer a single, simple security schedule that they can include in every contract, which receives as little opposition and changes from the supplier but still covers mitigates the key risks if things go wrong.

Writing a KISS version of a security schedule

These are not written more in common sense English than strict legal speak, also they are to be used completely at your own risk. So either way your lawyers will want to review them, let them do that and save a master version with your master contract template which you can then comfortably re-use.

First tip: a lot of what security professionals are worried about are already in the body of the contract – there is rarely any value in repeating these statements, unless you want to make them a lot more specific. So review your current default master template (or ask the sourcing / legal staff what they typically copy when they have to arrange a new contract) before you start. The common clauses you do not have to worry are the confidentiality clause, the right to audit, BCP/DR, negligence for transfer of a virus, staff background screening, awareness, training and other HR matters, staff fit for purpose, and regular contract monitoring meetings but feel free to add them in if they are missing.

You will also need to add to certain sections outside the security schedule, I mentioned service penalties above, the other two obvious areas are definitions (e.g. define security incident) and services (if there are any on going security services like monitoring or vulnerability scanning that you also want to outsource).

Second tip: why reinvent the wheel? There are industry standards for what is considered security best practice, auditors have lots of copy paste audit work papers to test them and are prepared to give you someone else (potentially with deeper pockets) to sue by signing a clean certification every year, six months, quarter etc. This is what will let you cut the bulk of the security clauses in your contract while still gaining the risk reduction benefit, I mean afterall, look at your own policies - what are they based on?  It is also what the regulators and industry bodies use as an objective standard and what you waste millions of hours doing “gap analysis” against. If you had a gun to your head and you had to write your top 10 security controls, there is a good bet almost all of them would be in the ISO 27001 standard (access controls, anti-malware, secure configurations etc) and written a lot better than you could due to years of negotiating and review by hundreds of security professionals.

In addition using industry standard measures provides you a level of future proof-ness e.g. PCI-DSS was recently updated (even though very little changed), a reference to comply with PCI would not need to be changed, a copy paste of the clauses into the contract is not so lucky.

If like most security people, you are not entirely comfortable with this approach (and because it represents change) consider the practicality: the more clauses you include the more time it will take to agree the contract and the more lawyers that look at it the more slight modifications you will be forced to concede without any real idea whether they have changed the meaning.

Therefore consider the following:

Supplier shall ensure that the Solution and Services are certified, by an independent auditor, on an annual basis, as complaint throughout that year to the current version of:

a) ISO 27001 / 2
c) SAS 70 Type 2

The Supplier shall provide the certifications in reference to the Customer in writing within 20 business days of date

Both Parties agree that the certifications in reference above can be provided to Customers of the Customer in the contract, other third parties and regulators where the Customer is contractually or legally obligated to do so

Remove any that do not apply e.g. PCI-DSS if you do not handle credit card data. Add things such as HIPPA if you have medical data, for nearly all cases I would keep ISO 27001 and SAS70 Type 2. Read some of these again (try Instapaper for when you are on a train or plane), try a search for anything you immediately think is missing, you will be surprised that it will most likely be there, if not organised how you would organize it.

Third tip: Do include some additional clauses for the highest risk areas to your business. This is the 20% that will provide you 80% of the value. Again remember that the goal is prevention of a security incident and the ability to effectively and objectively measure security compliance during the contract.

These will also change with time, e.g. consider that 10 years ago laptop encryption would not have made this list, 5 years ago removable media encryption and data loss prevention would have struggled to get a mention. Security is an arms race, what is acceptable changes with time – make sure you have a process to revise these at least annually and if there is a security incident or near miss.

Personally I consider the following some of the most important:

  • Any Information classified as Customers rating shall be encrypted at all times in storage and transfer

  • Any information related Solution and Services stored on removable media (CD/DVD/USB/Backup tape), mobile devices and laptops shall be encrypted (include only the information classification if you get push back on this one, I would not concede on backup tapes – insist that either they do not backup to tape or they encrypt them).

  • Supplier shall ensure that people, process and technology measures are in place to prevent the data leakage and/loss for any information classified as Customers rating related to the Service and Solution

  • Customer shall have the right to perform security testing including security penetration tests and site visits to all sites relevant to the Solution and Service. (Note how this is a more specific right to audit to make it crystal clear)

  • Supplier shall remediate any security vulnerability relevant to the Solution and Service at no additional cost to the Customer. High risk vulnerabilities shall be remediated (including confirmation via retesting) within 10 business days, medium risk vulnerabilities within 40 business days. (Substitute dates with what you are comfortable with and what the supplier will accept at a reasonable cost, assumption is that low risks will be BAU or risk accepted)

  • Customer shall have the right to have direct access to all original systems and information involved in any security incident relevant to the Solution and Service

  • Customer shall have the right to perform monthly, quarterly and annual reviews of Suppliers compliance with this Schedule (again a more specific clause on the regular monitoring)

No comments:

Post a Comment


Written by