Recent news about the SolarWinds compromise and Trojan horse introduced in their software raises a question: How can organizations ensure the security of their supply chain?
By Kevin Reed, CISO at Acronis
I am not alone in this and there were a few takes on how one could guarantee the security of their suppliers. I think you cannot. Or, more specifically, it’s prohibitively expensive and unless you are a government organization, you cannot afford this. Here, I should highlight that there are reports of the U.S. Treasury (https://www.reuters.com/article/us-global-cyber-usa-idUSKBN28Y09L) and Department of Homeland Security (https://apnews.com/article/solarwinds-hack-email-top-dhs-officials-8bcd4a4eb3be1f8f98244766bae70395) being affected by the SolarWinds attack among others, so, apparently, even they failed at solving this problem.
Current approaches to supply chain security mostly boil down to two methods: questionnaires and third-party scans and evaluations.
In my experience, filling in generic questionnaires is mostly a waste of time for multiple reasons. First, your supplier may not even know the answers to some of the questions. For example, according to IBM (https://www.ibm.com/security/digital-assets/cost-data-breach-report/#/), it takes 280 days on average to identify a data breach. This means, a request to “indicate data breaches took place over the last 12 months” may make no sense at all because the organization is still to discover them.
Second, your questionnaires may not expose the full picture: indeed, setting the right question, one needs to know half of the answer. I am not saying, your suppliers will intentionally hide facts from you or openly lie in their answers, however, some may exaggerate a little, and others can exaggerate more. For instance, there was a supplier who claimed to have “robust and comprehensive security policies in place”, which turned out to be a page or two in the employee’s handbook. Although it’s still better than nothing, it’s quite a stretch from “comprehensive.” Worst of all, often, you cannot validate some of the answers, you simply have to believe what was claimed.
Another approach is to outsource risk evaluation to a third party in a form of technical vulnerability scans or compliance-like reports like SOC2. SOC2 report quality is largely dependent on the auditor’s professionalism and wiliness to present independent and honest opinions. We know that auditors are supposed to do so, but we also know about the role of Arthur Andersen in the Enron and WorldCom scandals. Of course, I am not saying every auditor is dishonest, however, bear in mind, that unless you are not paying for the audit, you are the customer. Also, experience tells me that the quality of reports done by larger auditors is often worse than those of smaller companies specializing in cybersecurity and cyber risk management.
Are third-party scans the solution?
Third-party security scans are slightly better, but not by much. Again, from my experience, they are vulnerable to what’s called the “Streetlight effect” – they are looking for what is easy to find and not for what matters. For example, TLS misconfigurations for public servers are easily testable: as a result, such reports are often filled in with warnings about how dangerous it is to have 3DES cipher enabled on a Web site. While 3DES is a legacy algorithm, there are no practical attacks on the algorithm itself and the SWEET32 is not really a threat for a typical Web site. At the same time, such third-party scans are completely blind to having a 20-year-old, not updated Linux box on the internal network and could be compromised with an off-the-shelf exploit by a script kiddie. They are blind to SQL injections or other kinds of attacks in custom Web applications, which is relatively easy to find with a semi-manual analysis, but not easy to scan for.
As a result, a company may focus on looking good on those scan reports instead of the underlying security issues. In a way, this is similar to a “compliance-driven security” phenomenon, where organizations are so focused on filling in the checkboxes, they miss the real security issues. An example would be Target’s data breach: Target was PCI DSS certified, yet cybercriminals managed to hijack its payment terminals at some 1800 stores and steal at least 40 million credit cards. I believe we will see companies with excellent third-party ratings successfully hacked.
So, are we doomed? How can you reliably validate the security of your supply chain?
Here are a few things to look at. There’s no guarantee, but they give me and my team more confidence than anything else.
Before you even start evaluating your vendor for security, consider the impact of their compromise on your company. You might not have the capacity to do a full risk assessment, but at least consider a worst-case scenario. What impact will there be, if the vendor’s systems were encrypted in a ransomware attack? How will you be affected if their source code was compromised and a Trojan horse was planted in their software? What will happen, if the vendor’s databases were compromised, data stolen, and/or sold? The answers will be different for a cloud provider where only your encrypted backups are stored versus a company you outsource your ERP or HR system to. Estimate your risk based on what this particular vendor does for you. Consider specific scenarios that are relevant to your relationships and work on them.
Next, you turn to the vendor. The first thing to look for is whether the company has dedicated and competent people focused on security. Do they have a security manager or maybe even a CISO? Not every company needs a CISO, small and medium businesses often don’t have an appointed CISO, and that’s fine. A CISO could be outsourced, that sometimes is fine, too. The important thing is, someone is responsible for the security and can respond to your questions if needed. Just don’t bother them with filling in questionnaires.
Now, when you know your risks and who is responsible for eliminating them on the vendors’ side, ask them, how are they doing it. This could be an email or a 30-minute meeting with a pre-arranged list of adjusted questions, or both. What works for me is email, followed by any clarifications over a call, but it all depends on you and your vendor’s working style, time zones, level of relationship, and risk.
By this point, you should have a basic risk assessment and risk mitigation plan. Now, you need to validate it.
Request for evidence of what’s being claimed. I find pentest reports useful, not even because of their content, but sometimes due to the very fact that the company does them. Watch for the pentest scope and ideally request a report for two consecutive tests to verify that the company is acting on the findings.
If they are your software supplier, ask for an independent source code review. Those are expensive and not every company can afford them, but if they do, it’s a good sign. Also, not every company is willing to share the full report for various reasons, often citing NDA due to the source code snippets included in the report. A lot of legal formalities could be involved, so sometimes an executive summary might be enough. Again, consider your level of exposure and the risks you are taking. Another important sign for a software supplier or a cloud provider is if they are running a bug bounty program. Bug bounty programs are great because they can act as an external validation of the software quality. However, equally important is how fast the company is able to fix the findings. Prioritization, say, based on CVSS score or other established methodology is a sign of a mature vulnerability management process. Public bug bounty programs are a sign of the company’s confidence in their ability to properly handle the reports, but private bug bounty programs have their advantages too, and they are perfectly acceptable especially at the early stages.
Will scanning help?
For cloud providers, it may make sense to scan their networks but first, taking a few things into account: chances are you will not find anything Shodan (a search engine for internet-connected devices) did not find already, so maybe a Shodan search will suffice. Alternatively, you can ask them for a report of their own scans.
Scanning is not hard, setting context is harder. Also, the very existence of the report is an indication they are managing their attack surface. Yet, if you are still willing to scan yourself, obtain a permit from them, and ask them to segregate customer addresses from their own, otherwise you will be scanning something irrelevant.
For non-cloud companies, it could be impractical to scan, because much of their applications will already not be on their networks, but in the networks of the aforementioned cloud, SaaS, and PaaS providers. However, what is useful for almost any kind of company is to request their patching reports: again, the very existence of such a report is a sign they are managing vulnerabilities and have software in place to look at it. Willingness to provide such a report shows their confidence in their patching practices. Ideally, the report should be produced by an independent entity, but this is hard to obtain in real-life situations.
There, now you have your risks identified in relation to this particular vendor, you understand the treatment of those risks and you have evidence that the necessary actions are actually taking place, you will be able to take a picture of the situation and will know how to proceed from there.
Conclusion
How often should you repeat such an exercise? The common approach is to do this annually. However, it can depend on the risk and potential impact. For a low-impact vendor, you may do it less often, and for one, you depend on significantly, you may need to develop a permanent evaluation process. The tricky question here is if the vendor will be willing to invest their time in this. Does the cash flow justify their involvement? You may discover that your leverage against large SaaS and IaaS providers is literally none so likely they will have a “take it or leave it” attitude. Luckily, these vendors can invest more in securing their networks and systems, and overall, they are not necessarily the weakest link.
A few takeaways:
- Adjust your approach to risk you are exposed to by using a particular vendor. Most have little potential impact, focus on those that do.
- Outsourcing risk evaluation to a third party may not work. They don’t know your risks and really important vulnerabilities are hard to uncover in an automated fashion.
- Aim for consistency and watch for risk that changes over time — this is a marathon, not a sprint.
About the Author
Kevin Reed is the CISO at Acronis, a top global cyber-protection company. Reed has over 20 years of in cybersecurity and has supervised the security strategies of leading world banks, the 10 billion NASDAQ traded search engine, and more.
Disclaimer
Views expressed in this article are personal. The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.
