Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.
News, news analysis, and commentary on the latest trends in cybersecurity technology.
ASM Can Fill Gaps While Working to Implement SBOM
If compiling a software bill of materials seems daunting, attack surface management tools can provide many of the benefits.
Jonathan Care, Contributing Writer
December 6, 2022
5 Min Read
Source: paulaphoto via Adobe Stock
A software bill of materials (SBOM) is an important tool enterprise defenders can use to track the impact of software security bugs, manage sane patch management, and protect the integrity of the software supply chain as a whole. Scores of industry leaders say so. The Office of the President of the United States says so.
So why are they not widely used yet? What are software vendors worried about? Do they know something that we don't?
In a recent CISO Forum in Whitehall, London, many CISOs felt that the challenges and speed of change in application security, particularly in a cloud-enabled environment, had left them a little nonplussed and challenged to change their architectural models and thinking to become fully cloud native. In particular, there was a reluctance to let go of legacy control methods such as IP-based access lists and endpoint-based security controls.
Hesitant to Set Off the SBOM
There are several interesting possibilities that may be driving the tendency to delay providing SBOMs.
The first is ignorance of their own supply chain. It's possible that the vendors don't actually know the origin of some of their software. It is common practice in large development teams and long, complex projects to effectively "black box" entire sections of code.
If that is the case, the fact that the organization may not fully know the origins of its software raises a myriad of concerns. It could indicate anything from bad version tracking to the existence of potentially indispensable employees that hold the fate of the entire company in their coding hands. It's completely understandable that such a company would hesitate to release SBOMs for its products.
Another scenario that might make a company leery of SBOMs is if the product is almost entirely an assembly of other products. It's the reality of modern software development that programs are the result of custom code cobbled together with third-party libraries and components. If the company has written a very low percentage of its own code, then the SBOM could essentially become a recipe card for someone else to clone the product.
But the likely scenario is that software firms may see no upside, only potential downside to releasing SBOMs. Currently there's very little market pressure on releasing SBOMs for their product lines. They may have created one for internal use, but there is no real push to make them public. The main concern voiced by CISOs is that while an SBOM may improve visibility, it provides little impetus towards remediation and no liability for fixing software flaws — leaving the problem squarely in the lap of the end user, the CISO.
Getting Past the SBOM
It's unlikely that the industry or the purchasing public will be able to generate the market pressure required to force every major player to release an SBOM for all their products. In May 2021, the US government issued an executive order to improve the nation's cybersecurity that explicitly called for SBOMs as a control measure for the software supply chain. The EU government, for its part, has planned a Cyber Resilience proposal to echo and support the requirements of the US order.
If the main purpose of an SBOM is patch management and vulnerability attribution, there is a secondary layer of monitoring and protection that cybersecurity personnel should be looking at: attack surface management (ASM).
While it would be slightly easier for enterprise security teams to know that the software they use contain packages X, Y, and Z, that isn't the only way to manage application security. By tracking the security advisory history of these software suites, we can estimate the most likely attack vectors that they can fall victim to.
The combination of these vulnerabilities compiled from every piece of software that a company uses makes up an organization's attack surface. What ASM tries to do is intelligently categorize these weaknesses and automate the discovery, remediation, and continuous monitoring of new threats.
It's like tying together a vulnerability advisory service with an enterprise software management solution. The way that the ASM does this varies from product to product, but generally some amount of machine learning is involved. That way predictive models can be built so that when certain zero-day exploits are discovered, you will know how likely they are to apply to your attack surface even if you don't have a detailed SBOM from every vendor.
A good ASM has the additional benefit of treating ducks like ducks. You know: If it looks like a duck and quacks like a duck, it doesn't really matter if someone else labeled it as a swan instead. The ASM only cares about results. If a company insists that it's using the Open Dynamics Engine, but for some mysterious reason it falls victim to all the same vulnerabilities as the PhysX engine, ASM will completely ignore labels and suggest the fixes that actually fit the situation and not the ones that correspond to the names.
Even if the movement toward mainstream adoption of SBOM continues to be slow, security professionals have a strong alternative with ASM. It's also worth noting that ASM will complement any SBOM-based software governance with a dynamic risk mitigation system.
Instead of adopting and deploying something locally to cover your vulnerability discovery and monitoring needs, another alternative is to embrace an agentless security model that can monitor extended asset attack surfaces. The device intelligence firm Armis, for example, does this with a fully cloud-native approach. Think of it as an ASM solution that covers IoT devices, cloud instances, and edge networking setups, as well as traditional on-premises.
Such a model presents a different, more global way of looking at asset intelligence that might be more attractive to large enterprise operations. Smaller operations, however, would likely want to save their money for a good ASM and rely on extra vigilance for their extended network devices.
About the Author(s)
Jonathan Care is a recognised expert in the field of Cybersecurity & Fraud Detection. A former top-rated Gartner analyst, Care was responsible for defining the Fraud market, and leading Gartner’s Insider Threat and Risk research. He regularly advises cybersecurity industry leaders on strategic growth and has worked with key figures in industry and government across the globe. He is a lead contributor for Dark Reading, an industry-defining publication.
Care has testified in court as an expert witness and forensic investigator and is a Fellow of the British Computer Society. He also fuels his creative passion as a composer of film/TV music.
You May Also Like
Your Everywhere Security guide: Four steps to stop cyberattacksFeb 27, 2024
Your Everywhere Security Guide: 4 Steps to Stop CyberattacksFeb 27, 2024
API Security: Protecting Your Application's Attack SurfaceFeb 29, 2024
API Security: Protecting Your Application's Attack SurfaceFeb 29, 2024
Securing the Software Development Life Cycle from Start to FinishMar 06, 2024
Latest Articles in DR Technology
Apple Beefs Up iMessage With Quantum-Resistant EncryptionFeb 23, 2024|5 Min Read
Insurers Use Claims Data to Recommend Cybersecurity TechnologiesFeb 22, 2024|4 Min Read
AI-Generated Patches Could Ease Developer, Operations WorkloadFeb 20, 2024|5 Min Read
What Using Security to Regulate AI Chips Could Look LikeFeb 16, 2024|3 Min Read