Understanding Cybersecurity Supply Chain Risk Management (C-SCRM)

Image

Cybersecurity Supply Chain Risk Management (C-SCRM) deals with more than protecting an organization from cyber-attacks on third parties. It also addresses third parties to those third parties (known as “fourth parties”). Further still, a vendor to your vendor's vendor is a fifth party, then a sixth party, etc. Your SCRM should involve knowledge of how far, complex and even convoluted your supply chain is. Then measure this complexity with your risk appetite. (You might wonder, "What happened to the second-party?" Those are your members and customers.) What really makes the difference between C-SCRM and any other kind of technical vulnerability management (VM)? There really isn't much difference in the tactics used. What becomes essential in C-SCRM is that the technical aspect of VM gets done and gets done well. With C-SCRM, managing and monitoring aren’t optional. If a company has a relatively small number of third-party vendors, then there may not be too much more to do than a typical VM program. But if one has a multitude of third parties, then it's inevitable that the total number of suppliers increases exponentially. This factor immediately leads to numerous vulnerabilities for which your company is responsible to manage. While it may seem unfair that you have to manage those vulnerabilities, in the end, your customers are relying on you to provide a solid product and service. Digital transformation imposes and increases third-party risk. Two primary threats in the increasingly outsourced digital economy are:

1. Lack of full control
2. Lack of full visibility

Is there any data to show that third-parties are really such a serious risk? According to Verizon's 2019 Insider Threat Report’s “5 Types of Insider Threats,” the 5th type of insider threat is the Feckless Third-Party, described as follows: "Business partners who compromise security through negligence, misuse, or malicious access to or use of an asset." C-SCRM is based on knowledge. As such, the DIKW model is a handy overview here. “D” is for “Data,” “I” is for “Information,” “K” is for “Knowledge,” and “W” is for “Wisdom.” More specifically, input for C-SCRM is found in the D-I-K tiers.

Image

With C-SCRM, the aspects of DIK can be addressed with technologies (especially those leveraging AI) such as firewalls, spam filtering, EDR and DLP. The “Wisdom” tier is relegated to experienced personnel who determine what to do with all of that DIK. Technology can send plenty of bits and bytes to the governance committee, but it can't decide traits like a company's risk appetite, product direction or security budget. How does one decide how to proceed with all of that info? Think of the visual arts. A vital aspect of visual art that makes it viable art is boundaries; there has to be some kind of border. It could be comic book panels, the borders of the canvas, the limits of the monitor, a scene in a film or a character's silhouette. When creating C-SCRM programs, there have to be borders. No organization can possibly handle the entirety of the intel that's available. Even if it could, not all of it matters. This is why even the most complex VM tools filter data. With any C-SCRM, you want to know what information is coming in and going out. With the supply chain, especially digital, you now have an exponential amount of data being transferred. As a sample, any and every time a department buys new software for that department, there's one if not multiple new threat vectors. Unless that vendor and the software has been vetted, then that purchase has created a blind spot. Not surprisingly, there are plenty of aspects to consider in C-SCRM. Here's how one might outline them:

• Inventory
  1. All assets – hardware, software, personnel, contracts
     1. This is a usual project for any company that hopes to maintain good security, but here the focus is on where these assets interact with third parties. Hardware and software are pretty straightforward, but personnel and contracts might not be. An example of these categories is knowing where one company shares confidential customer or corporate information with all other companies. Where that data is shared, can the security of those repositories be verified?
  2. Timing of inventory updating
     1. Do you need to scan for installs and be alerted to installs once a week? Once a day? Immediately? This needs to be done to ensure that software assets aren’t connecting to unapproved sources, which risks opening more holes in your firewall and weakening your security.
• Impact Analysis
  1. What technical threats are truly threats to the organization?
     1. Realistic Threats & Risks
        • There are innumerable threats every hour, but what threats really apply to you? A foreign state might be on the list of threats, but is the chance of that threat materializing as great as the chance that an RDP/3389 port (opened for your contractor) would be noticed on a Shodan scan and exploited?
     2. Here’s an example: in Q2 2020, the risk from personnel working from home hit an all-time high, whereas in Q1, your company might have had minimal risk from remote work. Changes can happen quickly and en masse, so be ready to analyze those changes for the ways that they can negatively affect your security.
        • As a reminder of changing one’s risk appetite, while the risks with work-from-home increased, for many companies, the advantages increased just as much. Changes aren’t all bad; they need to be approached from other angles than just straight-up security threats.
     3. Categorize and Classify
        1. C-SCRM would take account of all of the vendors, categorize them as to whether they pose a technical threat, classify those which are – at the very least – critical in severity, determine which suppliers further down the chain need to be verified for their security posture and begin the process of security attestation reviewing and reporting.
• Intelligence

The Intelligence step is where you take all of the threats that could materialize from and through your suppliers and cull those possibilities to produce better data sets that would produce actionable steps. Unless you are certified in app/web testing and the supplier has paid for your testing services, the likelihood of being able to directly test a vendor's apps and sites is zero. So, feel free to ask for any kind of third-party testing results for your X-party suppliers. If acceptable to the requesting organization, the supplier’s internal ISMS documents or program can be requested in lieu of third-party testing. There are many paid and free tools available for gathering threat intel. While your supplier may not have direct threats that can be monitored, there are likely extant threats – such as vulnerabilities in the codebase that are outsourced by the company responsible for creating your software – that affect that company. Those threats can be monitored.

• Integration

Integration is taking the garnered intelligence and putting it into place in your network. In exploring the tools found in the Intelligence phase, the more you can streamline the integration of that data into your environment, the better. Monitoring, alerting & reporting are in this stage. Each product is different, so in vetting the product, especially for vital data (e.g., Critical alerts of anomalous activity), ensure that it will actually produce email or text alerts.

• Improvement

Maturing the processes is always on the project board. In Year One, it might suffice to use a spreadsheet to keep track of assets by using a service on lower-end server to scan your network. But Year Two may require a more robust software tool for asset tracking and a higher-end server for real-time scanning. Alternatively, your internal alert ratings could change. What was Low priority last year might now be High and need to re-labeling. Correction is part of this phase. Are there new suppliers? Are there former vendors that no longer need any kind of access but for which there’s still an IP address opening on your firewall and servers? Correction can be addressed with recurring projects. Set-it-and-forget-it makes it possible.

• Incident Response

Before embarking on a C-SCRM plan, have an IR plan. Bad things happen at any time, and they don’t wait until programs are fully developed. If a successful attack were to occur, it's likely that it will happen before the program is completed because the unfinished program has more security holes in it than a completed one. What are your communication channels (e.g., call tree)? Who will you contact if the app you just installed company-wide has a bug? Which person at Company X will you call if there's malicious traffic flowing from that supplier? Who is your contact for the worst-case scenario of a breach in that supplier? Test the People, Processes and Technologies involved in the IRP. How and when will you practice your IR plan? After testing, produce the results according to your BC, IR and DR policies. In responding to incidents, it's important to focus on defense, not offense. (NOTE: Unless you have some special authority, "hacking back" is not a valid response.) Each of these steps may end up becoming quite complex, which is precisely why C-SCRM is so difficult. The concepts are quite common sense, but the tremendous amount of detail and the lack of a one-size-fits-all approach makes it appear onerous. What is to be done if your company is part of someone’s supply chain? Ask yourself, "What are the chinks in my armor?" Maybe the armor imagery isn't your thing, but what will help your program is making it personal. Maybe you like basketball or football and want to think of it as setting up a defensive move. Or you're in finance and think of Red Flag warnings. In looking for how to better protect your company's network, it may help to start calling it "your" network and see, as objectively as possible, where your network has holes. Depending on a company’s criticality in the chain, customers may ask for your vulnerability assessment results. These are typically considered "for internal use only." By not sharing them, you're not avoiding being honest or vulnerable (see what I did there), but there are many ways that those reports can be misunderstood. An example of misunderstanding can occur when internal corporate vulnerability scans assess both Prod and Test servers. If the reports reflect both, then the Test environment is likely filled with holes on purpose. Internal staff will understand the results, but external parties will not and may well consider the team lax in their duties – even if they are on top of the situations. If vulnerability assessments aren’t shareable, at minimum have a professional response ready for those inquiries and provide some metrics by which prospects and risk assessors can measure the internal security of the product or service to which they’re uploading their data. Here’s a recently developed tool from NIST that can help as you develop and mature your C-SCRM.

Image

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.

More From Ross Moore about Supply Chain Risk Management

1. Supply Chain Risk Management – What You Need to Know to Build a Successful SCRM Program