Don’t Overlook Software Vulnerabilities
During talks in the 1980s, President Ronald Reagan learned a Russian proverb and quoted it during meetings with Mikhail Gorbachev. The proverb — trust, but verify — was later adapted by U.S. Secretary of State Mike Pompeo, then in talks with China, who said, “Distrust and verify.”
This philosophy is reflected in the current cybersecurity aspiration of zero trust. The risk of cybercrime is too great to allow for trust. Though business relationships, especially business-to-business ones, may be based on trust, a debate over software vulnerability management remains. Supply management organizations, with software platforms being key components of their operations, must be able to engage in detection to protect themselves and their customers as they engage with third parties to do business.
Detection and Disclosure
For supply management organizations, with software platforms being key components of their operations, understanding responsibility and disclosure is the first step to security. Let’s start with identifying and disclosing software vulnerabilities.
Researchers and developers dispute where responsibilities lie for early detection and disclosure. Recent well-publicized software supply chain attacks were not surprising to the cybersecurity community. Developers can be lax at testing their own software for vulnerabilities, and glaring holes can be left open for years.
When researchers find issues, they’re often torn between anonymously making them public or notifying the developer. This is because developers have sought cease-and-desist orders or have pressed criminal charges against disclosing researchers. This has even occurred where bug-bounty programs, in which a reward is offered for information on new vulnerabilities, are in place.
Globally, the laws protecting vulnerability disclosure are weak, and developers often act to suppress disclosure rather than have it properly placed in MITRE Corporation’s publicly disclosed common vulnerabilities and exposure (CVE) database. Placement in the CVE database, a shared documentation of all known vulnerabilities and points of exposure, is fundamental to all cybersecurity efforts. This disagreement has caused vulnerabilities to linger, allowing for further attack.
However, delay in disclosure can open up liability for fines from U.S. Securities and Exchange Commission (SEC) violations. Legal and financial liability is clear, reinforced by legal rulings. Also, the issue has captured more attention from shareholders and the media.
Considerations
These are just the table stakes. The ones at risk are the customers — the companies using the software. Should companies take on the responsibility for finding vulnerabilities in the products they purchase? They likely won’t have testing and research arms, and so will be able to look for only known, disclosed vulnerabilities. However, there is zero obligation for developers to provide these. The burden then falls on the customer.
Some considerations:
Know outsourcing vulnerabilities and plan around them. Supply management organizations and other companies that outsource parts of their operation may think they are also outsourcing security and software management. To an extent, they are, but they retain legal liability. And as the party with that legal liability, it is in their self-interest, even if only financially, to consider themselves responsible for detection of attacks. Detection should be a layer on your network, regardless of any vulnerability, known or unknown.
Vulnerability scanning tools and disclosed indicators of compromise (IOCs) are the informing source. They rely on public disclosure to automate detection — and no company could provide a detection function without them. It’s critical that providers embrace this ecosystem.
Open source opens the door to transparency. While the scale for vulnerability identification and disclosure can be shifted toward the developer, it needs to shift to the customer for mitigation. This is not the case for software-as-a-service (SaaS), where patches are handled by the provider.
On-premises or privately hosted software should not rely on the provider for deployment and patching. Too many dependencies create complexities that only the provider can assist with. Any automation developers provide for patching needs to run under the watchful eye of proper change management. They aren’t off the hook because they need to make patching and remediation easy and supported while raising the level of communications and transparency. It’s something they can learn from the open-source movement.
While it’s safe to assume the lack of transparency will largely remain a part of doing business for most companies, it is for this reason that open-source software has become a viable option. The open-source movement exists partly because of the lack of transparency in the software supply chain. Large providers with wide market reach typically guard their software, wary of proprietary intellectual property being examined by competitors or bad actors with malicious intent. Open-source software, on the other hand, is transparent, allowing for external study and encourages discovery and discussion of vulnerabilities in software.
The concern about lack of transparency is that disclosure of vulnerabilities and attacks can be delayed or hidden to protect a provider’s reputation. The law is already clear on the disclosure requirement. The SEC has recently fined companies that failed to disclose breaches and were accused of defrauding investors by hiding that data. Without access to code, there is no way to know what it contains. It could even be a back door, which is why some Chinese products have been banned by the U.S. government. Researchers can do amazing things even with a black box, but developers that provide their source code get more help in finding holes and therefore are more trusted.
Policy as effective policing. One solution is to create and support auditing organizations that can institute software testing standards. Testing could be done either with the cooperation of the software developers — or by external auditors — though regulations could force developers to submit to testing, assuming that software testing doesn’t become an expected part of doing business. At minimum, a software bill of materials could be provided, as the federal Cybersecurity and Infrastructure Security Agency (CISA) has advocated.
As cyberattacks increase in scale and scope, and enforcement agencies take them more seriously, there will be a greater requirement for retention of data for forensic examination and legal discovery. Proper detection by all parties aids investigation, informs the security operation, and can protect the company from legal liability. Also, by establishing a system of retaining data for this purpose, an organization is relieved of the burden of scrambling to collect data, delaying any forensic work and creating a large project for its team at the same time it’s trying to mitigate any potential attacks or breaches.
Mitigating Risk
The instinct for self-preservation will always prevail. Outsourcing work does not mean outsourcing risk, and assuming a provider will look out for your organization’s interests is unwise. Your organization’s cybersecurity must be a priority, and actions providers might do to protect you should be seen as supplementary — because legally, financially and reputationally the responsibility remains with you.
Beyond ensuring your organization is “covered,” consider that collaboration and transparency in vulnerability identification and network detection improves security for all involved parties. Ingesting provider intelligence and telemetry is necessary for holistic coverage and to be able to detect compromises from all lateral, ingress and egress points on the network and hosted workloads.
Regulation and compliance may be necessary to encourage providers to (1) be open with their customers about software vulnerabilities and (2) embrace researchers. While collaboration in vulnerability identification and network detection may eventually become a standard part of good business, such an effort will be essential in fighting cybercrime. An unknown vulnerability or the lack of an IOC is a gap in detection for attackers to exploit.
(Image credit: Getty Images/Yuichiro Chino)