There is a story from years ago about a warehouse network of computers that was separated from the main network. Those machines were running older OSes. But since they weren't connected to the company network, didn't hold company data, and only ran the warehouse machines, they were deemed secure. One day, the sysadmin noticed that all of those computers had a glitch at the same time. He remotely rebooted and went back to his desk. But they all glitched again. What happened? Even though they were not connected directly to the network, they were connected to Wi-Fi, which ran directly to the internet. Their vending machine sat on that same Wi-Fi network, and unfortunately, that particular vending machine vendor had been compromised. The virus traveled through the network to the vending machine and then to all the computers that were connected to the same Wi-Fi network. Supply chain security – it matters. Fortunately, there was only some downtime. No damage was done, and no data was lost. The event detailed above raises some important questions. What's connected to what? And just as important, who is connected to what? That’s where Supply Chain Risk Management (SCRM) comes in. The main purpose of this blog post is to address the overall task that I’ll refer to as SCRM. The topic above can actually be considered Cybersecurity SCRM (C-SCRM), and, because that’s a more technical aspect, I will cover that in the next article.
Building a SCRM Program
There are 3 main areas in an SCRM program: managing the vendors, mitigating the risks, and maturing the program.
Management of the Vendors
The typical vendor management (VM) program, which is part of the whole SCRM process, should contain at least the following items:
- Policies and procedures for vendor management
- This is to ensure that your vendor management person can take a vacation and that consistent action can be taken when the primary person is absent.
- A vendor attestation review process
- A repository for keeping all of the documents on a year-by-year basis
- A schedule for when to request the latest security attestation, financial, et al. documents
- A rating system for determining the criticality of the vendor and determining which classification needs attestation review
- A vendor performance rating or scoring system
- Contacts for each vendor
- Someone, perhaps even a department, that is responsible for requesting, reviewing, classifying and coordinating this process
Take note of who is in your network of suppliers. The number of suppliers and vendors will vary greatly depending on your business. The usual advice applies here: “You don’t know what to protect until you know what you have.” Even for fairly small businesses, the number of documents – virtual or not – can be daunting. This highlights the importance of selecting the right place to put them all and to back it all up! Next, decide how complex your attestation puzzle will be. Will you just go with your vendor's SOC 2 report? Or do you also need proof of security and compliance from other vendors in the chain? It's typical to review the third-party and then one more level down. For example, if your vendor has a SOC 2 report for their product, which is stored in a hosted data center, then the usual request will be the vendor’s SOC 2 and the SOC 2 (or other report) for the host. But if the vendor’s data center also has services carved out in another vendor’s hosted data center, the decision becomes whether or not to get that fourth party’s attestation report. Keeping communication lines open is essential. You will think of all kinds of questions to ask the vendor. "How are you dealing with this latest vulnerability?" "When do you expect you'll be up-to-date with the new XYZ state regulations?" Having contacts, even a direct support line (which may, of course, come at an increased cost) is a must-have for this step. Also, think about the SLA. If it's not specified in the SLA, then something that calls for urgency on a customer’s part (e.g., remediating security issues quickly) won't be a requirement for the vendor. The customer may want it fixed in a few days, but the vendor might not view the urgency in the same way. It could even be considered a low priority for them. Make sure to determine the business strategy for reducing and managing the attack surface. Increasing the number of vendors, thereby decreasing the level of corporate liability, is one strategy. A breach in one of many vendors might be disruptive but not so much if one held most or all resources and then one’s own systems were attacked. This strategy spreads out the attack surface. (A drawback could be that the increased cost of managing so many vendors may present an economic risk. There's a financial cost to managing and monitoring those vendors.) Of course, reducing the number of vendors, thereby decreasing the attack surface, is another strategy. There can be less headache and hassle in managing just one’s internal resources, potentially saving the company a lot of money and time. A couple of drawbacks are increased need for internal expertise and increased need for internal support hours.
Mitigation of the Risks
Beyond just technical cybersecurity risks (which will be covered in another article), a few other types of risks exist.
Financial Risks
How would your company be affected if your vendor or one of their vendors became insolvent? What if your storage vendor in the chain was acquired? What would happen to your privacy and security agreements? Keep an eye out for vendors that would be able to provide the same service in case of emergency. Providers like PaaS and IaaS are plainly not as volatile or easily switched as something like your snack vendor, so the risk will be determined by what you provide along with any other considerations you might need to switch service providers.
Operational Risks
What happens to the contracted services or products if there’s a service disruption at one or more of the suppliers? Business continuity and disaster recovery are important here. At a minimum, a TTX should be performed to think through and communicate what needs to happen in case of extended outages. Procurement is part of this risk. Have a holistic process that includes knowledge of intent to purchase (by someone in a management or director positions), knowledge by security (so they can vet the proposed purchase) and involvement of IT Operations (so they know what tech might be needed or impacted).
Privacy and Regulatory Risks
What is the course of action for a customer's data getting viewed/taken while held at a vendor? It’s important to know the requirements for reporting and notifying if there’s a breach at a vendor. A Mutual Non-Disclosure Agreement (MNDA), while not impervious, is a good baseline contractual agreement between the customer and supplier. These agreements can be complex, but they should at least cover the need to keep shared information confidential and to lay out the repercussions for a breach of contract. Expect to sign or receive many of these.
Software Risks
What if the software that’s used, even if it’s approved, has bugs? What kind of Software Development Life Cycle (SDLC) does the vendor or their suppliers use? Are software contractors properly vetted? Does the supplier have an MDM or BYOD policy? Do you need to compare the hashes of the programs downloaded on corporate computers?
Reputational Risks
This is arguably the largest risk because it directly affects the long-term viability of your company. Who wants to do business with a company that doesn’t have the security foundations done correctly? Consider how much revenue could be lost if your company’s reputation took a hit because of poor security practices. This loss isn't just how a brand is initially impacted; it’s also about how longevity and stability are measured (e.g., how many people were let go and how much the stock dropped in value). How does one figure out the reputational risk rating? Fortunately, searching for “reputational risk assessment template” will uncover plenty of resources. For security professionals, the ability to demonstrate reasonable security measures and/or SANS Institute industry certifications can go a long way toward increasing the company’s reputation. Being able to produce appropriate publicly accessible reports, policies and processes will greatly increase trust.
Maturity of the Program
An old adage is, “You get better at what you do.” The excitement of getting any program together often provides enough energy to complete the program and get it started. But it’s the long haul, the growing up phase, that becomes tough and requires staying power. Maintaining the SCRM requires good project management skills as well as cooperation and communication between many departments. Business, regulatory, compliance and legal risks determine to what extent companies require attestation and what certifications are needed. Consider your company’s reputational requirements. This is about increasing your reputation. Because customers are aware of third-party risks, your reputation will increase if you are known to review current and potential vendors and can prove that you’ve reviewed the risks and responded accordingly. These actions, in addition to having set up an SCRM program, also set up a company for a successful audit whether required (e.g., because you're in the financial industry) or self-imposed (e.g., voluntarily seeking SOC 2 or ISO 27001). Be open, honest, and organized. A great help to maturing one’s SCRM program is letting others know where the security posture stands, what’s being done to refine it and what the future plans are. “How do I know what to do to improve our program, and what customers are looking for?” Role-play as if you're one of those vendors. You may not have regulatory requirements, and you may not be a SaaS, but you will benefit from acting as a top-notch company that protects your customers’ data. Also, think about what assurances you want from those who hold your data. What guarantees do you want from the bank or your children's primary care provider? What protections are expected from social media platforms? When you think about what you would like personally, you can then expand those things to what your customers would expect from you. And then you can extrapolate from those expectations what you need to receive from your vendors. Make a note to consider potential litigation. Look ahead and imagine the scenario of you sitting in a courtroom and being questioned by an attorney. "Did you know about this risk? Did you do anything about it? Do you have regular reports of risk and threats? Are you aware of how your team is managing and monitoring vendors? Do you have processes and projects in place to locate, manage and mitigate vulnerabilities?" The questions will go on and on. Crimes and accidents happen. They always have, and they always will. But that doesn’t make it any less important to ensure you have done all that can be reasonably performed to anticipate and mitigate bad possibilities. This process is called “duty of care” or “due diligence.” The concept is about making sure you have done your best to secure what you know you need secured in an appropriate manner. The last aspect that I’ll mention and one of the first things to accomplish is developing an Incident Response Plan (IRP). Be ready to respond. While preparing, implementing and growing your program, things can go wrong. Having a plan for how to respond to incidents in general (and more specific as time goes on) is a critical piece of maturing your program.
The Value of a SCRM Program
Manage your vendors, mitigate the risks and mature the program. As your company becomes better able to demonstrate diligence to protecting your customers' data, trust will increase. And a good name is worth its weight in gold. A good resource for further perusal about creating a SCRM program is NIST's SP 800-161, “Supply Chain Risk Management Practices for Federal Information Systems and Organizations.” This publication is located here: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf.
About the Author: Ross Moore is the Cyber Security Support Analyst with Passageways. He was Co-lead on SOC 2 Type 1 implementation and Lead on SOC 2 Type 2 implementation, facilitated the company’s BCP/DR TTX, and is a HIPAA Security Officer. Over the course of his 20 year IT career, Ross has served in a variety of operations and infosec roles for companies in the manufacturing, healthcare, real estate, business insurance, and technology sectors. He holds (ISC)2’s SSCP and CompTIA’s Security + certifications, a B.S. in Cyber Security and Information Assurance from WGU, and a B.A. in Bible/Counseling from Johnson University. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
Zero Trust and the Seven Tenets
Understand the principles of Zero Trust in cybersecurity with Tripwire's detailed guide. Ideal for both newcomers and seasoned professionals, this resource provides a practical pathway to implementing Zero Trust, enhancing your organization's security posture in the ever-evolving digital landscape.
