I've excerpted discussion out of context from a recent thread. The thread itself is long and there were posts intertwining, but these deserve separate discussion, unique from the scope of the original thread. And the subject matter is important.
Quote:
Originally Posted by betweendayandnight
...please answer me with a "Yes" or "No"...
1. Is it sufficient for me to just apply [these particular patches]...in order to have a secure...hardened and stable...operating system?
2. If I don't apply the [other patches]...will my operating system ... become insecure...and unstable?
|
These are two wonderful questions. Firstly, because they reflect a common perception:
Security is something you can install. Second, because they conflate
security and
stability, which I will leave to another post in this thread.
Is security something you can install?
At first glance, this certainly appears true. And depending upon your definition of the word "security" -- it might
be true. There are entire worldwide marketplaces full of IT products and services and and consultancies to address aspects of IT security. But just what is security? How do we define it? And, once we've defined it, how do we assure we have it, and retain it?
In the context of the referenced thread,
betweendayandnight wanted clear and unambiguous confirmation that a properly patched OS would be secure -- "hardened" -- and that no insecurities would remain.
If "hardened" means, "No known vulnerabilities exposed," then the answer could be the simple
yes that was desired. But what about
unknown vulnerabilities? Zero-day vulnerabilities exist in all sorts of software and hardware. Can we prove it? Not until such vulnerabilities have been exposed a posteriori. For this OS in question, two remote vulnerabilities have been previously exposed during its history. Will there be any others in the future?
Almost certainly.
I state that because the software is undergoing continuous development. It does not stay static. There are advantages to the development -- vulnerabilities are addressed as they are discovered. But there are risks to development, in that new features and functionality and code rewrites may introduce new vulnerabilities. The auditing process and focus on quality practices mitigates risk, but does not eliminate it.
So by this initial definition of security, it is a constantly moving target.
Quote:
Originally Posted by ocicat
Security takes constant vigilance.
|
Additionally, many types of "security" definitions are partially or completely outside the scope of the OS itself, requiring other considerations. Two examples: Authentication -- verifying and validating users and applications -- and Authorization -- determining which users or applications can access specific services or specific types of information.
Let's return to that system which has no known vulnerabilities exposed. Let's give that system to any of
us to use.
Quote:
Originally Posted by ocicat
...An improperly managed system...can result in a system which is insecure....How people fiddle with permissions, or install unknown applications, or share passwords is completely out of their control.
|
We, as administrators, may inadvertently "soften" the hardened system. How? We provision it. We add third party software. We configure applications, network interconnections, and services. We do this because we want to get utility from information technology, and any OS, as shipped, needs some provisioning to be used.
I can't agree with the perception of security-as-product. Not directly. If we modify the perception, broadening the view of what security actually is, perhaps something akin to, "Components of a secure application infrastructure may be addressed by technologies you can install," will get my concurrence.