Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Database Security
Authentication
Mobile
Privacy
Compliance
Careers and People
Identity & Access Management
Security Monitoring
Advanced Threats
Insider Threats
Vulnerability Management
Comments
The Real Wakeup Call From Heartbleed
Newest First  |  Oldest First  |  Threaded View
planetlevel
planetlevel,
 User Rank: Author
4/20/2014 | 12:38:43 PM
Re: But assurance equals accountability equals liability.
I think you're confusing insurance with assurance. If I provide some kind of warranty, guarantee, or underwriting of a piece of software, then sure, I'm on the hook.  But I disagree with your assertion that assurance necessitates this type of liability.

I don't view assurance as a black-and-white situation.  And neither did the authors of the Orange Book.  All the problems you mention could be easily verified by a set of automated tests delivered with the software.  You don't have to get all the way to formal methods and proof-carrying code to gain assurance.

Give me some software with some reproduceable test cases, the results of some testing tools, let me know a little bit about who wrote it, what tools they used, and their process and I'm probably in a lot better situation than if I just download some code off the Internet.
Interesting
Interesting,
 User Rank: Apprentice
4/18/2014 | 7:15:30 PM
Re: But assurance equals accountability equals liability.
As an IT Auditor who worked with one of the big five (before they became the big four) global audit firms, I can only suggest that our definitions of assurance are vastly different. Arthur Andersen certainly found it out the hard way. Would you bet all your assets on making an assurance claim? That's assurance in writing, which is what my post refers to. Legal liability for making such an assurance. Any other form of assurance is just hot air if not in writing, IMHO. As before, testing may give the tester some assurance, but others just have to trust the tester's results. Considering that compilers can optimize security code out of the app, thereby leaving the app open to compromise, then reviews of the code are not 100% guaranteed to find bugs (since compiler optimizations may remove that code altogether at compile time, therefore it never makes into the binary). Thus assurance relies on library versions, compiler versions, compiler flags (very important), the platform it's built on, how the libraries were built, library compiler flags, ... It's non-trivial to provide assurance that is actually worth anything without providing a signature on a legal document to that effect. Would you really risk all your personal assets to assure some large Government that your software project has no bugs? Finding a new bug after you've given assurance then makes your assurance worthless. Yet we keep finding new bugs. It is difficult and expensive (if not impossible with a large enough infrastructure) to prove the non-existence of any bugs. Languages like Ada try to help in this regard, but writing something non-trivial in Ada is beyond most coder's tolerance levels. I feel that being able to sue for providing false or misleading assurance (once a new bug has been found in the assured codebase) will not help open code development in any useful way. It is likely to have the opposite effect. And assurance without any ability to sue is meaningless, as there is zero risk to the assurer in that case. Thus every two bit developer will provide that sort of assurance. Individuals and companies are welcome to obtain levels of assurance commensurate with their risk appetite and budget. But requiring some other entity to provide assurance is simply buck passing. Due diligence is the responsibility of the user, not the provider. I agree that it is a truly desirable feature, and in the Utopian ideal world we would have assurance for every line of code. We're not in Utopia yet though...far from it.
planetlevel
planetlevel,
 User Rank: Author
4/18/2014 | 6:19:49 PM
Re: Assurance Evidence
I wrote a nice tool to generate these labels automatically.  If anyone is interested in making an open-source tool out of it, I'd be happy to share.
Marilyn Cohodas
Marilyn Cohodas,
 User Rank: Strategist
4/18/2014 | 5:10:06 PM
Re: But assurance equals accountability equals liability.
I really like your analogy comparing software assurance to a supply chain for software. I don't think it's too much to ask that  we hold software to the same standard: that the components that go into developing bsiness logic, code etc. adhere to some industry agreed upon baseline. 
Marilyn Cohodas
Marilyn Cohodas,
 User Rank: Strategist
4/18/2014 | 3:58:16 PM
Re: Assurance Evidence
Love the label!

planetlevel
planetlevel,
 User Rank: Author
4/18/2014 | 3:36:01 PM
Re: Assurance Evidence
I'm glad you asked.  Here's a presentation I did a few years ago proposing just such a thing.

https://www.owasp.org/images/1/17/2010-11_OWASP_Software_Labels.pptx

What's fascinating to me is that the actual label doesn't seem to matter much.  Even if software *users* don't care about the label... the fact that there is a label means that companies *producing* software will do a better job so that it doesn't look awful on the label.
planetlevel
planetlevel,
 User Rank: Author
4/18/2014 | 3:33:31 PM
Re: But assurance equals accountability equals liability.
I agree with you that liability is not helpful for application security, although there are many who keep bringing up the idea.   However, I don't think that assurance necessarily implies accountability or liability.

I worked on the OWASP Enterprise Security API project for several years, and we provided a large test suite (thousands of tests), ran static analysis tools on the code, had the code manually reviewed by several large companies, and talked the NSA into doing their own review (they made no code changes).  You can choose to accept or reject any or all of that evidence, but I believe that it adds assurance.  And none of it was particularly difficult to do.  The test cases in particular *saved* us considerable time.

You don't have to jump to formal methods to get assurance.  In most cases, a modicum of evidence that basic security tests were performed would be a radical improvement.

However, I don't agree that assurance work necessarily increases anyone's liability. The license can still be a standard free and open software licence.  You don't have to warrant that your code is fit for any particular use.  The point of the article is just that unless the market starts demanding better assurance, heartbleed-style vulnerabilites will be with us forever.
Interesting
Interesting,
 User Rank: Apprentice
4/17/2014 | 7:12:39 PM
But assurance equals accountability equals liability.
Agree that assurance is a desirable feature. But assurance implies accountability, which implies liability. If the software is developed for free and given away for free, and the license clearly warns you that it is provided "as is", etc then it is up to you, the user of the software, to determine it's suitability for your purpose. ie: if you want assurance on a free product, then you are free to obtain it, using whatever funds you have available to employ appropriate developers and testers. Or do you wish to make the developers liable for damages as a result of your use of their free library (which as above already contains the "Use at own risk, supplied as is, where is, ..." disclaimer to prevent that exact scenario)? If giving away free software suddenly came with a legal liability (the assurance), then it would almost certainly cease all open source development efforts immediately, since few individuals have the necessary funds to fend off a liability claim of the magnitude of this recent bug. The other ways of gaining assurance involve very expensive code audits and mountains of testing (neither of which actually prove the non-existence of bugs, it only proves that the tests and audits found no bugs. Two very different things.) If you truly want assurance then it can be achieved only via program proving, but going down this path could be frightfully expensive. No software vendors have ever, in my experience, provided an assurance that the software works correctly in all scenarios. Specifically they say the exact opposite in almost every software license I've ever read. Most if not all contain the words: "This software is provided as is. Use at own risk. No guarantees on fitness for purpose." This includes Microsoft, IBM, Oracle, Amazon.... If none of the big vendors will/can do it... If they do, then there is always an escape clause that allows them the opportunity to fix it without being liable. So there goes any assurance provided by that agreement, as the only assurance provided is that bugs will be fixed in a timely fashion, not that bugs do not already exist in the code.
Marilyn Cohodas
Marilyn Cohodas,
 User Rank: Strategist
4/17/2014 | 9:09:49 AM
Assurance Evidence
Curious, Jeff. What do you think a "Software Facts" label should include?
rjthomas01
rjthomas01,
 User Rank: Apprentice
4/17/2014 | 3:47:42 AM
Good balanced view of software
Nice article; maybe- just maybe- Heartbleed will wake people up that no form of IT is a magice bullet impervious to faults. We're lukcy this time in that we're primarily a Windows shop and have therefore bypassed OpenSSL, but that's really just luck. Next time it oculd be a fault with SChannel, or something else. The potential for faults is limitless. The keys are to patch (preferably automatically), have multiple security gateways and try to embed security practices throughout an organization.


Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The 10 Most Impactful Types of Vulnerabilities for Enterprises Today
Managing system vulnerabilities is one of the old est - and most frustrating - security challenges that enterprise defenders face. Every software application and hardware device ships with intrinsic flaws - flaws that, if critical enough, attackers can exploit from anywhere in the world. It's crucial that defenders take stock of what areas of the tech stack have the most emerging, and critical, vulnerabilities they must manage. It's not just zero day vulnerabilities. Consider that CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilitlies in widely used applications that are "actively exploited," and most of them are flaws that were discovered several years ago and have been fixed. There are also emerging vulnerabilities in 5G networks, cloud infrastructure, Edge applications, and firmwares to consider.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2023-1142
PUBLISHED: 2023-03-27
In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use URL decoding to retrieve system files, credentials, and bypass authentication resulting in privilege escalation.
CVE-2023-1143
PUBLISHED: 2023-03-27
In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use Lua scripts, which could allow an attacker to remotely execute arbitrary code.
CVE-2023-1144
PUBLISHED: 2023-03-27
Delta Electronics InfraSuite Device Master versions prior to 1.0.5 contains an improper access control vulnerability in which an attacker can use the Device-Gateway service and bypass authorization, which could result in privilege escalation.
CVE-2023-1145
PUBLISHED: 2023-03-27
Delta Electronics InfraSuite Device Master versions prior to 1.0.5 are affected by a deserialization vulnerability targeting the Device-DataCollect service, which could allow deserialization of requests prior to authentication, resulting in remote code execution.
CVE-2023-1655
PUBLISHED: 2023-03-27
Heap-based Buffer Overflow in GitHub repository gpac/gpac prior to 2.4.0.