{{Header}}
{{Title|title=
Reasonable Security
}}
{{#seo:
|description=Definition of "reasonable security". What does the mean?
}}
{{maintainability_mininav}}
{{intro|
Definition of "reasonable security". What does the mean?
}}
= Introduction =
{{stub}}

= Miscellaneous Viewpoints =

{{quotation
|quote=
When is a program secure enough?

* Security is all about tradeoffs
** Performance
** Cost
** Usability
** Functionality
* The right question is: how do you know when something is secure enough?
** Still a hard question
** Requires understanding of the tradeoffs involved
* Is Internet Explorer secure enough?
** Depends on context
|context=[https://scholar.google.com/citations?user=19kNRU0AAAAJ Steve Zdancewic, Professor of Computer and Information Science, University of Pennsylvania]: [https://www.cis.upenn.edu/~stevez/cis551/2006/web/lectures/CIS551-01.pdf Computer and Network Security]
}}

{{quotation
|quote=Security is meant to prevent bad things from happening; one side-effect is often to prevent useful things from happening. Typically, a tradeoff is necessary between security and othe r important project goals: functionality, usability, efficiency, time-to-market, and simplicity
|context=Dr. Bill Young, Department of Computer Sciences, University of Texas at Austin: [https://www.cs.utexas.edu/~byoung/cs361/lecture2.pdf Foundations of Computer Security, Lecture 2: Why Security is Hard]
}}

Coined "practical security" instead of "reasonable security" but a similar concept.

{{quotation
|quote=Practical security balances the cost of protection and the risk of loss, which is the cost of recovering from a loss times its probability.
|context=2000: [https://en.wikipedia.org/wiki/Butler_Lampson Butler W. Lampson], Microsoft, [https://www.cs.cornell.edu/courses/cs5430/2023fa/NL02.Lampson.pdf Computer Security in the Real World] <ref>
https://www.acsac.org/2000/papers/lampson.pdf
</ref>
}}

{{quotation
|quote=As secure as reasonably practicable means that an incremental improvement in security would require a disproportionate deterioration of meeting other system cost, schedule, or performance objectives; would violate system constraints; or would require unacceptable concessions such as an unacceptable change in the way operations are performed.
|context=[https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology National Institute of Standards and Technology (NIST)]: [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v1r1.pdf Engineering Trustworthy Secure Systems]
}}

= Qubes Viewpoint on Reasonable Security =
{{quotation
|quote=Creating Qubes OS has been a great challenge, especially for such a small team as ours, but ultimately, I'm very glad with the final outcome – it really is a stable and reasonably secure desktop OS. In fact I cannot think of any more secure alternative...

I use the term “reasonably secure”, because when it comes to defensive security it's difficult to use definite statements (“secure”, “unbreakable”, etc), unless one can formally prove the whole design and implementation to be 100% secure.
|context=Security researcher and Qubes founder, Joanna Rutkowska, [https://theinvisiblethings.blogspot.com/2012/09/introducing-qubes-10.html Introducing Qubes 1.0!]
}}

{{quotation
|quote=In Qubes OS we took a practical approach and we have tried to focus on all those sensitive parts of the OS, and to make them reasonably secure. And, of course, in the first place, we tried to minimize the amount of those trusted parts, in which Qubes really stands out, I think.

So, we believe Qubes OS represents a reasonably secure OS. In fact I'm not aware of any other solution currently on the market that would come close when it comes to secure desktop environment. But then again, I'm biased, of course ;)
}}

{{quotation
|quote=I wouldn't call Qubes OS “safe”, however, at least not at this stage. By “safe” I mean a product that is “safe to use”, which also implies “easy to use”, “not requiring special skills”, and thus harmless in the hands of an inexperienced user. I think that Apple iOS is a good example of such a “safe” OS – it automatically puts each application into its own sandbox, essentially not relaying on the user to make any security decisions. However, the isolation that each such sandbox provides is far from being secure, as various practical attacks have proven, and which is mostly a result of exposing too fat APIs to each sandbox, as I understand.
}}

{{quotation
|quote=Finally, even though Qubes has been created by a reasonably skilled team of people, it should not be considered bug free.
}}

{{quotation
|quote=“We don’t make empty promises to our users that we know no one can deliver on,” he said. “We do, however, find it amusing that many security experts around the world have deemed a ‘reasonably secure’ operating system to be the most secure operating system available.”
|context=Andrew David Wong (@adw), interview in Hosting Advice: [https://www.hostingadvice.com/blog/qubes-offers-security-by-compartmentalization/ Security by Compartmentalization: Qubes is an Open-Source OS Tackling the Most Sophisticated Modern Threats]
}}

{{quotation
|quote=
... for years we have been, similarly, assuming the underlying hardware, together with all the firmware that runs on it, such as the BIOS/UEFI and the SMM, GPU/NIC/SATA/HDD/EC firmware, etc., is all... trusted.<br />
But isn’t that a rational assumption, after all?
|context=Security researcher and Qubes founder, Joanna Rutkowska: [https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf Intel x86 considered harmful]
}}

Her answer, simplified: "No". Long answer:

{{quotation
|quote=Well, not quite: today we know it is rather unwise to assume all hardware and firmware is trusted. Various research from the last ten years, as discussed below, has provided enough evidence for that, in the author’s opinion. We should thus revisit this assumption. And given what’s at stake, the sooner we do this, the better.
}}

This topic is elaborated on the [[Open-source_Hardware|Open Source Hardware]] wiki page.

{{quotation
|quote=Defensive security is a difficult game, because one doesn't immediately see whether a given solution works or not. This is in stark contrast to other engineering disciplines (and to offensive security) where one usually have immediate feedback on whether something works well or not.
|context=Security researcher and Qubes founder, Joanna Rutkowska: [https://blog.invisiblethings.org/2012/06/27/some-comments-on-operation-high-roller.html Some comments on "Operation High Roller"]
}}

{{quotation
|quote=Occasionally fuckups happen, even with [https://www.qubes-os.org/security/bulletins/ Qubes] (although not as [https://www.qubes-os.org/security/xsa/ often] as some think).

What should we – users or admins – do in such a situation? Patch, obviously. But is that really enough? What good is patching your system if it might have already been compromised a week earlier, before the patch was released, when an adversary may have learned of the bug and exploited it?

That’s an inconvenient question for many of us – computer security professionals – to answer. Usually we would mutter something about Raising the Bar(TM), the high costs of targeted attacks, attackers not wanting to burn 0-days, or only nation state actors being able to afford such attacks, and that in case one is on their list of targets, the game is over anyway and no point in fighting. Plus some classic [https://xkcd.com/538/ cartoon].

While the above line of defense might work (temporarily), it really doesn’t provide for much comfort, long term, I think. We need better answers and better solutions. This post, together with a recently introduced feature in Qubes OS 3.2 and (upcoming) 4.0, is an attempt to offer such a solution.
|context=Security researcher and Qubes founder, Joanna Rutkowska: [https://blog.invisiblethings.org/2017/04/26/qubes-compromise-recovery.html Compromise recovery on Qubes OS: individual VMs & full system cases]
}}

"Solution" is a somewhat non-ideal wording in this context. What is offered is not a full solution but rather a mitigation. Specifically, a compromise recovery method using Qubes backup restoration in paranoid mode. This mitigation does not fundamentally alter the broader situation, where attackers generally retain an advantage over defenders.

{{quotation
|quote=The inconvenient and somehow embarrassing truth for us – the malware experts – is that there does not exist any reliable method to determine if a given system is not compromised. True, there is a number of conditions that can warn us that the system is compromised, but there is no limit on the number of checks that a system must pass in order to be deemed “clean”.
}}

= User Perspectives =
Qubes forum discussion: [https://forum.qubes-os.org/t/qubes-os-a-reasonably-secure-operating-system/31799 Qubes OS A reasonably secure operating system?]

{{quotation
|quote=I think the idea behind using ‘reasonable’ is to eliminate the false promise of ‘ultimate security’ - As that is simply not exist.

Even ‘security’ alone is not a well defined term, but a process to address your threat model. As that should describe your goals and the things you want to ‘protect’ from different kind of threat actors.
[...]
So it is reasonable secure, as there is no ultimate security. And because it is provides you the best available and feasible soultion to address a lot of security concers related to a desktop computer - but surely not all of them.
|context=https://forum.qubes-os.org/t/qubes-os-a-reasonably-secure-operating-system/31799/11
}}

{{quotation
|quote=Yes and no, depending on whose language you use when using the word “prove”.

If you’re a mathematician, you might say yes (as in a mathematical proof).

In the epistomological sense, no. There’s no way in hard science to prove you are secure. You can only prove you are reasonably secure, having migitated all the known flaws.

I assume this is why Qubes OS makes claims that it is a “reasonably secure OS” - not that it is a “secure OS”.

It is the unknown flaws that may one day still threaten you, and there is no way to prove there are zero flaws left.
|context=https://forum.qubes-os.org/t/building-a-fully-immutable-linux-os-image-fully-verified-with-your-own-secure-boot-key/34412/19
}}

{{quotation
|quote=[..] Note that Qubes OS is a reasonably secure OS, not maximally secure OS. [...]
|context=https://forum.qubes-os.org/t/more-practical-security-for-qubes-and-more-realistic-threat-model/7349/17
}}

{{Footer}}
[[Category:Documentation]]
[[Category:Design]]