Today’s ICS software is never written from scratch. Vendors focus development resources on core competencies and prefer to buy (rather than build) components available off the shelf, such as license managers, installers, and cryptographic libraries. This strategy, while efficient in terms of development effort, entwines the vendor’s security posture with multiple suppliers and open source projects. Worse, it makes it difficult to see what exactly is included in a package. In 2018, asset owners were exposed to
critical vulnerabilities in the Gemalto Sentinel License Management Software because major ICS vendors quietly embedded it in their products and ICS operators didn’t know. And searching the CVE databases didn’t help as the vulnerabilities appeared under Gemalto rather than the vendor names.
ICS vendors deal with a similar challenge: their developers rely on libraries, frameworks, and other 3rd-party code to be efficient and avoid recreating proven functionality. In turn, these components usually have their own embedded third-party and open source code originating from widely-used repositories, such as GitHub, where attackers have been known to plant malicious code. And if their DevOps environment is lax about version control, the developers may unwittingly embed old versions of code with known vulnerabilities.
This talk introduces techniques to help both ICS vendors and operators assess the validity and safety of ALL the components of any given ICS package — before it is shipped or installed. We look at using a Software Bill of Materials to expose mystery components, and score each one for safety and security.
Learning Objectives- Understand the depth and breadth of embedded “mystery components” in ICS packages from both a vendor and asset owner perspective.
- Learn how to view the relationships between components, across multiple product lines and vendors.
- Explore tools and solutions for exposing and scoring components prior to installation on critical systems.
