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
100%
0%
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
50%
50%
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
100%
0%
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
50%
50%
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
100%
0%
Marilyn Cohodas,
 User Rank: Strategist
4/18/2014 | 3:58:16 PM
Re: Assurance Evidence
Love the label!

planetlevel
100%
0%
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
50%
50%
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
50%
50%
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
50%
50%
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
50%
50%
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.


News
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-3493
PUBLISHED: 2021-04-17
The overlayfs implementation in the linux kernel did not properly validate with respect to user namespaces the setting of file capabilities on files in an underlying file system. Due to the combination of unprivileged user namespaces along with a patch carried in the Ubuntu kernel to allow unprivile...
CVE-2021-3492
PUBLISHED: 2021-04-17
Shiftfs, an out-of-tree stacking file system included in Ubuntu Linux kernels, did not properly handle faults occurring during copy_from_user() correctly. These could lead to either a double-free situation or memory not being freed at all. An attacker could use this to cause a denial of service (ker...
CVE-2020-2509
PUBLISHED: 2021-04-17
A command injection vulnerability has been reported to affect QTS and QuTS hero. If exploited, this vulnerability allows attackers to execute arbitrary commands in a compromised application. We have already fixed this vulnerability in the following versions: QTS 4.5.2.1566 Build 20210202 and later Q...
CVE-2020-36195
PUBLISHED: 2021-04-17
An SQL injection vulnerability has been reported to affect QNAP NAS running Multimedia Console or the Media Streaming add-on. If exploited, the vulnerability allows remote attackers to obtain application information. QNAP has already fixed this vulnerability in the following versions of Multimedia C...
CVE-2021-29445
PUBLISHED: 2021-04-16
jose-node-esm-runtime is an npm package which provides a number of cryptographic functions. In versions prior to 3.11.4 the AES_CBC_HMAC_SHA2 Algorithm (A128CBC-HS256, A192CBC-HS384, A256CBC-HS512) decryption would always execute both HMAC tag verification and CBC decryption, if either failed `JWEDe...