Data Security

Mission Really Difficult: Securing Your Supply Chain

By Wendy Nather, Research Director at the Retail Cyber Intelligence Sharing Center

How do you secure that which you don't control? This is the big question for every enterprise, since no organization exists in a vacuum. From third-party commercial software (including operating systems) to open source, custom-written applications, SaaS providers to systems integrators, hardware suppliers, and business partners, there are plenty of attack vectors that cause concern. Larger enterprises can work with tens of thousands of third-party suppliers, all with varying levels of interest in and controls around security; smaller organizations may have trouble even discovering all the partners in their supply chain.

There are many ways to categorize third parties for security purposes; for this blog post, I'll focus on degrees of control you can exert over them. The general categories are:

1. Suppliers of data, hardware, or software that will negotiate security requirements, even after a partnership agreement is in place
2. Suppliers of data, software, hardware, or services for which you can specify your own security requirements
3. Peer partners with whom you may be able to negotiate requirements and agreements
4. Suppliers of data, software, hardware, or services who serve a large customer base and have only a "take it or leave it" policy on security requirements (though you can choose to shop elsewhere)
5. Suppliers of data, software, hardware, or services whom you are required to use, and negotiation isn't an option

The first category is the easiest to manage from a control point of view, but you have to make sure you're regularly performing quality and security checks and remediating as needed. For example, some organizations have a policy that states that if their developers use open source software or other third-party developed components in their code, the developer is personally responsible for fixing any security vulnerabilities; he or she can't just wait until the community provides a patch. The "you use it, you own it" philosophy ensures that developers treat their entire code base with the same level of care. Other organizations place strict controls on which third-party components and versions are permitted at all, and then manage their asset inventory closely. Scrutiny is important, not just for security reasons, but also for licensing.

In the case of data you receive from third parties, if you can change it, you can also filter it. Rather than blindly trusting all input, consider applying whitelisting rules to accept only the format and content you're expecting. Data streams with high integrity requirements will need to be filtered anyway, but it's a good idea to go above and beyond a basic virus-scan.

For categories two and three, the challenge lies in specifying your requirements up front. Requirements need to be objectively verifiable and unambiguous enough that they stand up in a contract, but complete enough to cover all the possible ways in which security can fail. Many RFPs and statements of work tend to fall back on lists such as the OWASP Top Ten or SANS Top 25, or on compliance with PCI-DSS, but those guidelines should be a starting point only. At the very least, make sure that the supplier will remediate any security vulnerabilities on their own dime, for the life of the contract. Doing so leads to arguments about what constitutes a vulnerability, but it's pretty hard to deny when a back door is in place or a security researcher has published an exploit. With a peer partner, negotiating may be trickier — and demands can go in both directions so be prepared to practice what you preach.

Scenarios four and five often leave scant room to maneuver. The critical period is before you sign the purchase order; the potential supplier's sales team may be more incentivized to allow security testing, license agreement changes, or special terms and conditions, especially if you're evaluating competitors. Beyond that, most organizations have to put efforts into monitoring, periodic assessments, and threat intelligence: sharing information with peers about which providers have better security, using a common framework for questionnaires and placing joint pressure on the provider to remediate problems. An important part of the relationship with providers is establishing strong communication channels and an incident response process.

Whatever measures you're able to take with third parties, it's critical to document them so that you can look across your portfolio and understand the different levels of exposure and risk. In some cases, you may make a note to renegotiate security requirements when a contract comes up for renewal; in some, the auditor will want to know what you can and can't change; in others, you might need to work through industry groups to validate and amplify your calls for improved security.

Above all, remember that you're not alone. As a CISO, I was often told, "You're the only one who is asking for this," but it's not true — and even if it were, it doesn't matter; someone has to keep raising the bar to benefit the whole industry.

About the author: Wendy Nather is Research Director at the Retail Cyber Intelligence Sharing Center (R-CISC), where she is responsible for advancing the state of resources and knowledge to help organizations defend their infrastructure from attackers. Wendy will be presenting "How to Stop Retail From Getting 0wned Wholesale" at InfoSec World 2016.


Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.