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
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.


COVID-19: Latest Security News & Commentary
Dark Reading Staff 4/10/2020
Zscaler to Buy Cloudneeti
Dark Reading Staff 4/9/2020
Researcher Hijacks iOS, macOS Camera with Three Safari Zero-Days
Kelly Sheridan, Staff Editor, Dark Reading,  4/3/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Yes, I do have virus protection on my system, now what?
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11669
PUBLISHED: 2020-04-10
An issue was discovered in the Linux kernel before 5.2 on the powerpc platform. arch/powerpc/kernel/idle_book3s.S does not have save/restore functionality for PNV_POWERSAVE_AMR, PNV_POWERSAVE_UAMOR, and PNV_POWERSAVE_AMOR, aka CID-53a712bae5dd.
CVE-2020-1801
PUBLISHED: 2020-04-10
There is an improper authentication vulnerability in several smartphones. Certain function interface in the system does not sufficiently validate the caller's identity in certain share scenario, successful exploit could cause information disclosure. Affected product versions include:Mate 30 Pro vers...
CVE-2020-3952
PUBLISHED: 2020-04-10
Under certain conditions, vmdir that ships with VMware vCenter Server, as part of an embedded or external Platform Services Controller (PSC), does not correctly implement access controls.
CVE-2020-4362
PUBLISHED: 2020-04-10
IBM WebSphere Application Server 7.0, 8.0, 8.5, and 9.0 traditional is vulnerable to a privilege escalation vulnerability when using token-based authentication in an admin request over the SOAP connector. IBM X-Force ID: 178929.
CVE-2020-1802
PUBLISHED: 2020-04-10
There is an insufficient integrity validation vulnerability in several products. The device does not sufficiently validate the integrity of certain file in certain loading processes, successful exploit could allow the attacker to load a crafted file to the device through USB.Affected product version...