How software descriptions can open the door to cyberattacks [Q&A]
The use of SaaS-based applications and systems has taken off in recent years, but that surge has highlighted a problem in the form of a lack of standardization for software descriptions across all types of systems.
This makes it much harder for IT teams to assess vulnerability levels across all the packages in an enterprise. But what risks does this pose and how can businesses tackle the problem? We spoke with Peter Lund, VP at operational technology cybersecurity company Industrial Defender, to discover more.
BN: Why is not having a defined standard for software descriptions such a problem?
PL: One of the key foundational items to any cybersecurity program is knowing what you have, including what software you are running in your environment. The recent focus on securing the software supply chain, particularly with the use of SBOMs, is a step in the right direction, but it will further highlight the lack of standardization for software descriptions.
As we go from analyzing a single software title to the potential analysis of thousands of packages that are built into that software title, it's going to become much more difficult to match these titles with disclosed vulnerabilities. The ultimate goal needs to be a reporting ecosystem that can be completely automated.
BN: Which types of system does this affect?
PL: Nearly every device in the world that runs software. Some simple examples are things like Java, mysql, cisco ios, openssl. These types of software titles are foundational to the world of computing and have been for decades.
A prime example of this is when you ask Cisco switch what firmware it's running. Their switching infrastructure is used widely in both IT and OT environments. This string of information describes what software the switch is running, a great start, and an experienced IT professional can make sense of what Cisco is trying to tell us. However, nothing in this string is standardized or machine-readable.
When you read about a vulnerability on the news that impacts Cisco switches, you are going to have to do lots of manual work to identify if your software or firmware version is impacted.
BN: What are the difficulties involved in trying to establish a description standard?
PL: Human intervention is critical to the software naming process today, and humans are not consistent. We speak different languages, have different customs, conventions and opinions. Software engineers within the same company working on the same project will all come up with different naming conventions.
Solving these problems requires the agreement, coordination and adoption of all the companies in the world who create, use or repackage software, and there are decades-worth of non-standardized descriptions out there that will live for years to come.
BN: How can existing data, such as software inventories, help?
PL: Existing data is a great place to start understanding not only what you have, but also the scope of the problem and the inputs and outputs that are needed to drive creation of a standard. It is nearly impossible to assess, protect and remediate what you don’t have visibility into.
BN: Is there a role for automation in creating software descriptions?
PL: Absolutely. Even without a standard, a machine-generated name starts creating some level of consistency. Having a large company like Cisco or Microsoft start doing this would move the needle in a major way. We can still leverage nicknames and aliases for convenience in discussions, but having a machine-generated name is crucial for standardizing software inventories, and ultimately, understanding vulnerability exposure and mitigation options.
Image Credit: alphaspirit / Shutterstock