Do You Feel Lucky?

by Hank Berkley
Contributing Editor

We think of third-party security as being a risk we take when vendors or business partners are integrated with our systems and networks, but data sharing and other business practices also bring challenges. Perhaps the best-known case is Facebook sharing data with Cambridge Analytica. The latter is out of business, but Facebook itself is feeling the pain the same as if it was a data breach – perhaps even worse. There are two lessons we can learn from this case. The first is that no matter how smart you are, there is no such thing as 100% security. The second is that you cannot delegate responsibility for security issues.

Facebook was forward looking enough to include contractual language in their arrangement with Cambridge Analytica. This is an absolute requirement today, even with business partners and customers with whom you have been dealing for many years. The actual language will vary based on the type of data and industry, but formally recognizing the risk and defining responsibilities is imperative. We are used to requiring repair people to have workers’ compensation insurance when they work on our premises as we don’t want to be financially responsible for an accident. You may even require that they have additional insurance incase they cause other damage while in your facility. Requiring that they follow reasonable security protocols is very similar.

Developing standard terms and conditions for all contracts is an undertaking that should be done by your legal and security people working together. The key is to be reasonable, but include everything you need in the way of security for worst-case scenarios. Typically, this is achieved by requiring certification with an industry standard framework such as NIST. If your team believes that the risk is low because of the type of data being exchanged or for some other reason, it is easier to make contracts less stringent than more.

In addition to setting the minimum requirements for third-parties, contracts should include rights for you to verify compliance. This could be anything from an annual attestation by the vendor to an on-site audit undertaken by your staff. You don’t necessarily need to pursue the verification, but it is important to have the right to do so.

Adding a contractual requirement to an existing agreement can itself be a challenge, but understanding a partner’s reluctance to do so may itself reveal some risk. You may not be able to get all of your agreements updated for years, but just because you don’t have the right to audit in a contract doesn’t mean you can’t review the security measures that your partners have taken. In the end, having a mutual understanding of the security positions of both firms is in everyone’s best interests. A breach doesn’t help anyone and neither side will come out as a winner.

As important as it is to develop legal guidelines that you are going to impose on others, it is equally important to recognize that the third-parties with whom you do business are looking at doing the same thing. They will be approaching you to modify contracts and to give them audit rights. You need to be prepared to respond to security questions and you may find that they are asking YOU to comply with standard frameworks. This is a situation where you can not only improve your security, but you can save time and money by being prepared.

As there are no universal standards applied for third-party security certification today, many companies are creating their own questionnaires and requirements. They may be unwilling to accept anything less than having a CISO complete and sign their specific form, but in practice it appears that many organizations are willing to accept alternative forms of documentation. Having a prepared synopsis of your security measures may save hours of time completing someone else’s form. But even if your form is not acceptable as a response, the material in it can assure you that you are providing a consistent response to all inquiries.

Other steps you should consider in advance are testing against standard security frameworks and becoming certified if it is appropriate. Having an independent firm attest that you meet applicable NIST standards or having an annual SSAE-16 audit or (for healthcare) being HITRUST certified may itself be adequate to comply with organizations that treat you as a third-party, including some government agencies.

It is important to recognize that having a documented security program and certifications should be seen as more than a way to check a box. It should give you faith in your own security preparedness. Of course, it IS possible to be too prepared. Next time we will review when enough is enough.