In a recent episode of the PrOTect OT podcast, Daniel Bardenstein shared valuable insights into the realm of SBOM. Daniel, the CTO and co-founder of Manifest, a company dedicated to creating an all-encompassing SBOM management tool, discussed how their product streamlines the SBOM lifecycle for security and procurement teams.
Before co-founding Manifest, Daniel commenced his career in Silicon Valley where he focused on creating enterprise security tools tailored for large enterprises, SOC teams, and federal agents. His journey also led him into government service where he worked on numerous high-stake security initiatives. Remarkably, he served as one of the key figures in the security of the COVID vaccines and was at the helm of ICS research within the Department of Defense (DOD). His multifaceted career also boasts of being the former director of the Hack the Pentagon program, before he transitioned to the Cybersecurity and Infrastructure Security Agency (CISA), guiding their technological strategy and delivery efforts.
Daniel spoke about the evolution of his understanding, starting from the IT security domain, emphasizing learning curve when thinking about security in Operational Technology (OT) environments. He highlighted how certain standard practices in IT, such as multi-factor authentication, often come with caveats when applied to OT. The intricacies of ensuring security in environments prioritizing availability and operations, where data confidentiality and integrity might take a backseat, were brought to the fore. He reflected on the complexities, reminiscing about instances where even a simple task like patching becomes an enormous challenge due to the location of the equipment, be it high in the sky, below the ground, or miles off a coast.
The definition of security, they explained, varies vastly depending on the context. For instance, security imperatives for a SaaS-based company differ greatly from those of a large Original Equipment Manufacturer (OEM) or those on the procurement side assessing vendor security. It's crucial to recognize the multifaceted nature of security in today's enterprise landscape. Given the omnipresence of software and security, it's not merely the domain of traditional IT or OT security professionals. Instead, a holistic approach is mandated where every individual, be it from marketing, procurement, or leadership, is engaged with and understands the significance of security.
Government's Role in Bridging the IT and OT Security Divide
Daniel reflected on the evolving role of government in orchestrating a more attention on the OT side of security. Drawing from his experience in government, Daniel stressed the significance of policymakers factoring in OT when framing security policies. He believes that the government holds the potential to significantly influence security practices, especially for companies hesitant about investing in security.
Reflecting on his time with the Defense Digital Service, Daniel shared a notable contribution the team made to Executive Order 14028. While the order addressed critical topics like SBOMS, EDR, and MFA, their key contribution was integrating the term "OT" alongside "IT systems". The original draft was primarily centered around IT systems, but with this critical addition, it emphasized that cybersecurity is not just an IT concern, but also an OT one.
Daniel also touched upon another initiative he participated in at CISA: the cybersecurity performance goals. The intention behind these guidelines was to simplify security measures for smaller entities, like rural utilities, who might find comprehensive standards overwhelming. Yet, one striking revelation from his stint at DOD was the noticeable communication gap between IT security and OT security teams within enterprises. Addressing this in a lighthearted yet impactful way, the guidance document recommended an annual social event, humorously coined as a "pizza party," where IT and OT security professionals could come together to foster better communication.
The challenges in advancing OT security is multi-dimensions, highlighting not only technological and policy issues but also human and organizational aspects that need to be addressed.
Getting into SBOMs – Software Bill of Materials
Daniel passionately discussed the benefits and significance of Software Bill of Materials (SBOMs) for both IT and OT environments. He emphasized that while there's no one-size-fits-all solution, SBOMs are equally, if not more, vital for OT given the longevity of software in the field.
Before diving deep, Daniel provided a brief rundown of what SBOMs are: likening them to an 'ingredients list' for software. The SBOM lists all third-party dependencies, their licenses, and possible vulnerabilities. This understanding is crucial not just for externally sourced software, but also for software developed internally.
Drawing parallels to everyday scenarios, Daniel provided several analogies to highlight the importance of SBOMs:
A significant advantage of SBOMs is the opportunity they offer to mitigate risks even before deploying technology. Daniel shared success stories of both IT and OT customers demanding SBOMs from their vendors. An accurate SBOM serves as a testament to the maturity of the product security team, giving buyers a sense of the product's risk even before deployment.
Post-deployment, the SBOM shifts to a monitoring tool. Drawing on an IT example, Daniel mentioned the Log4Shell vulnerability, underscoring how having a clear software inventory aids in swift responses to such threats. It equips companies with the knowledge of where specific software or vulnerabilities lie, and whom they should reach out to if there's an issue.
With SBOMs, businesses can ensure they know precisely what they are purchasing, negotiate security measures with vendors beforehand, and be better prepared to address vulnerabilities post-deployment.
Diving Deeper into OT Application of SBOM
Discussing his experience in the OT world, Aaron touched upon the complex process of upgrading control systems or designing new plants. He illustrates that when decisions are made to invest in equipment like turbines from GE, Siemens, or Toshiba, the primary focus is often on the mechanical aspects, such as engineering the electrical and mechanical components and optimizing efficiencies.
However, every piece of equipment comes with an integral software component. Despite this, Aaron laments that decision-makers frequently overlook the software aspect and are unaware of the critical questions they should be asking. As a result, they might unintentionally introduce software with vulnerabilities into their systems. Drawing from a past experience, he recalls a vendor who presented two options during a control system upgrade: a secure system and a cheaper, labeled "insecure" system. Despite the glaring security risk, the latter option was considered because of its cost-effectiveness.
Daniel drives home the point that risk acceptance isn't just a potential vulnerability—it's a financial liability. Accepting risk without sufficient understanding or data can result in costly repercussions down the line. He cites whispers about some major US financial institutions adopting a compelling policy: if a software vendor does not provide an SBOM, the institution demands a 20% discount. This discount represents the anticipated time, resources, and personnel expenditure required to understand and manage the risks associated with that software.
Daniel underscores that while achieving zero vulnerability is unrealistic, understanding and managing risk is essential. After all, at the end of the day, risks translate to monetary impacts and influence business processes. If vendors attempt to sell insecure systems without transparency, they should be prepared for pushback from informed buyers.
The Importance of Vendor Transparency in OT
Daniel stresses the significance of vendor transparency in the Operational Technology (OT) space, especially regarding the Software Bill of Materials (SBOM). He believes OT asset owners, as key beneficiaries of SBOMs, should demand clear insights into products they procure.
An ongoing misconception is that asset owners need to reverse engineer a product post-purchase to understand its composition, especially for legacy devices. But, Daniel likens this to ordering at a restaurant or buying cereal without knowing the ingredients. Just as diners shouldn't have to guess their dish's components, OT asset owners shouldn't bear the responsibility of dissecting a product to determine its make-up.
The onus should firmly lie on vendors to clarify their products' contents. If they refuse, it casts doubt on their trustworthiness. Before resorting to reverse engineering or similar methods, Daniel urges OT professionals to ask their vendors upfront for SBOMs, including for previously deployed systems. Doing so not only ensures clarity but also reduces unnecessary work for security teams.
It's Not Just About Patching Everything
Instead of a mere tool for patching or upgrades, the essence of SBOMs is to enlighten users, enabling informed decisions. Reflecting on his tenure with Security Operations Center (SOC) teams, Daniel recounts the struggles of handling an onslaught of alerts, which often overwhelm enterprises. His critique of the CVSS score reveals it as a limited tool when it comes to comprehensive vulnerability assessment.
Bardenstein introduces the synergy between SBOMs and the Vulnerability Exploitability Exchange (VEX). While the former offers clarity on risk, the latter provides machine-readable insights into vulnerabilities. This marriage of automation and structured data, he suggests, can minimize the arduous task of sifting through unstructured data. By embedding VEX into vulnerability management systems, organizations can optimize their efficiency.
As Daniel points out, vulnerability management is continually evolving. It now goes beyond mere severity metrics, encompassing exploitability, impact span, and more. With tools like SBOMs, organizations can pinpoint the assets vulnerable to specific threats. However, Bardenstein emphasizes the need to integrate these with asset management tools, underscoring the importance of understanding deployment nuances.
For Daniel, the end goal is clear: a streamlined system rich in actionable information. He stresses the complexity of patching procedures and highlights the need to ensure that efforts are directed where they matter most. The vision is to target vulnerabilities that pose the most tangible threats, ensuring a higher ROI on security endeavors.
Elaborating on the untapped potential of SBOMs, Bardenstein, with his background in data analysis platforms, views them as more than just compliance tools. Like logs aggregated into a SIM system, SBOMs represent a vital dataset waiting to be explored. Daniel's insights reveal that many asset owners have been in the dark about third-party software dependencies or unforeseen licensing issues. By reconceptualizing SBOMs as dynamic, actionable data, organizations can unlock new avenues for risk mitigation and efficiency.
Shifting the Security Paradigm
Throughout the podcast, Daniel consistently advocates for a paradigm shift in software security. Instead of burdening only the software consumers or asset owners, he pushes for shared responsibility with software suppliers. He draws parallels to the automobile industry's recall protocols, highlighting the glaring accountability void in the software realm. Bardenstein applauds the steps taken by companies like Schneider but emphasizes the need for broader industry adoption.
Listen to the Full Episode
This has been a brief summary of the discussion, shortened for brevity. For the full insights of the conversation, be sure to listen to the full episode here: https://podcasts.apple.com/us/podcast/the-protect-ot-cybersecurity-podcast/id1662081824?i=1000624030659
