CISOs’ role in identifying tech components and managing supply chains
In this Help Net Security interview, Nate Warfield, Director of Threat Research and Intelligence at Eclypsium, outlines the crucial tasks for CISOs in protecting supply chains and achieving comprehensive visibility.
Warfield also discusses the vital collaboration between security and development teams, the adaptation of supply chain security strategies to global regulations, and the need for proactive measures to prevent speed of deployment compromising security.
What are the main tasks that CISOs must lead to protect their organizations’ supply chains and improve overall visibility?
First and foremost, they must identify all technology components in their environment, from their data centers down to the phones in reception, security systems, access control, etc. The larger the company, the more challenging this becomes as old tech is still in use, tech that may have come as part of an acquisition (especially servers and infrastructure), and the myriad of BYOD in use by employees.
Every item in this list has a supply chain, which will differ by vendor and device model. There are (at least) two distinct supply chains: hardware and software. The software supply chain is the more mature of the two, as the concept of SBOM has been around for years, and, especially with open source, this can be easier to identify. Closed-source solutions create unique challenges as many incorporate open-source components – think Log4J – which may be less evident during an audit.
The identification process will never be “finished.” It will need to be performed on any new technology deployed in the organization, especially during M&As where vast amounts of tech – and technical debt – will be inherited virtually overnight.
A considerable amount of visibility can be established merely by knowing the organization’s tech stack end-to-end; when vulnerabilities arrive, the organization should ideally be able to determine if they’re impacted within hours. Discovery timelines measured in days/weeks are unacceptable, especially as attackers exploit vulnerabilities at scale within 1-3 days of disclosure, and even a few days to deploy a patch puts an organization at risk.
Auditing a hardware supply chain is exponentially more difficult, as vendors may or may not choose to disclose what their underlying operating systems are, what open source software they use, where they source the hardware components of their devices, what firmware runs both the device itself and its subcomponents – for example a router may run a Linux distribution, with an open source routing daemon, a motherboard from Supermicro, with high-speed NICs from Mellanox, a baseboard management controller from ASPEED with BMC code from AMI which itself is another version of Linux with its own SBOM.
With the apparent disconnect between security and development teams in software supply chain security, what strategies do you recommend to enhance collaboration?
A mature software lifecycle must involve a security team early and often. Both teams should understand that their roles are complementary and instrumental to the organization’s and its customers’ success.
A big problem today is that security teams are only involved at the end of a project as part of a “final sign-off” in many organizations. This creates friction between developers and security engineers; both may see the other as the root of the problem: “If these developers only wrote secure code, everyone’s lives would be easier.” and “Oh great, the security team is going to find a bunch of bugs and delay our launch. Again.”
Organizations that involve security teams with development during the initial stages of design and scoping and have a few security reviews during the development process allow bugs to be addressed early in the cycle and provide an opportunity for the security team to educate developers on standard insecure coding practices.
While no solution is perfect, this approach – adopted by companies like Microsoft in developing HyperV – helps avoid last-minute delays and animosity between the teams.
How should CISOs adapt their supply chain security strategies to new global cybersecurity regulations and standards?
This is a challenging question. Supply chain security is a relatively new concept that organizations may have put on the back burner due to the relentless barrage of vulnerabilities, zero-day exploit campaigns, ransomware, and the challenges of working in both a COVID and post-COVID world.
Understanding the need for a supply chain strategy and prioritizing it is the biggest challenge, and the problem is complex. It will require collaboration across executive, development, security, and legal teams, and the strategy will vary based on the organization and its business model.
As organizations rapidly adopt digital services, what measures do you recommend to ensure that the speed of deployment does not compromise supply chain security?
Supply chain security needs to be a priority early in the development lifecycle. At the very least, open-source libraries and components should be audited for known vulnerabilities, and it’s worth looking at the vulnerability history of a component.
A manifest of third-party components – hardware or software – should be maintained for each product so new vulnerabilities can quickly be triaged for possible impact on the business. Vulnerabilities will be found; this is unavoidable, but an organization with a strong understanding of all its dependencies is better prepared to respond when new vulnerabilities are disclosed or exploited.
As AI and machine learning become more prevalent in cybersecurity, what are the implications for supply chain security, and how can CISOs leverage these technologies effectively?
AI/ML will eventually be used for vulnerability research, both white and black hat. This will impact the ecosystem at scale as attackers continue to push lower and lower into the computing stack, looking for weaknesses and overlooked libraries – for example, NPM has had more than its share of malicious code added to countless modules.
It’s too early to know precisely the scope and extent to which this will be used, and whether AI/ML can find vulnerabilities faster or more effectively than current methods of reverse engineering, fuzzing, and code review is up for debate. The best an organization can do is start planning for the eventuality and have a roadmap for integrating AI/ML into its development lifecycle.