The passive state involves operating systems with built-in security utilities. These utilities
can be quite effective when enabled, but remain worthless until the system administrator
activates them. In the passive state, these utilities are never activated, usually because the
user is unaware that they exist. Again, the source of the problem is the same: The user or
system administrator lacks adequate knowledge of the system.
To understand the passive state, consider logging utilities. Many networked operating
systems provide good logging utilities. These comprise the cornerstone of any
investigation. Often, these utilities are not set to active in a fresh installation. (Vendors
might leave this choice to the system administrator for a variety of reasons. For example,
certain logging utilities consume space on local drives by generating large text or
database files. Machines with limited storage are poor candidates for conducting heavy
logging.) Because vendors cannot guess the hardware configuration of the consumer's
machine, logging choices are almost always left to the end-user.
Other situations that result in passive-state insecurity can arise: Situations where user
knowledge (or lack thereof) is not the problem. For instance, certain security utilities are
simply impractical. Consider security programs that administer file-access privileges
(such as those that restrict user access depending on security level, time of day, and so
forth).
Vendor Response
Vendor response has traditionally been good, but this shouldn't give you a false sense of
security. Vendors are in the business of selling software. To them, there is nothing fascinating about someone discovering a hole in the system. At best, a security hole represents a loss of revenue or prestige. Accordingly, vendors quickly issue assurances to allay users' fears, but actual corrective action can sometimes be long in coming.
The reasons for this can be complex, and often the vendor is not to blame. Sometimes, immediate corrective action just isn't feasible, such as the following: • When the affected application is comprehensively tied to the operating-system source
• When the application is very widely in use or is a standard
• When the application is third-party software and that third party has poor support, has gone out of business, or is otherwise unavailable
System Flaws or Deficiency of Vendor Response
System flaws or deficiency of vendor response are matters beyond the end-user's control.
Although vendors might argue this point furiously, here's a fact: These factors are the second most common source of security problems. Anyone who subscribes to a bug mailing list knows this. Each day, bugs or programming weaknesses are found in network software. Each day, these are posted to the Internet in advisories or warnings. Unfortunately, not all users read such advisories.
System flaws needn't be classified into many subcategories here. It's sufficient to say that a system flaw is any element of a program that causes the program to
• Work improperly (under either normal or extreme conditions)
• Allow crackers to exploit that weakness (or improper operation) to damage or gain control of a
system
In these instances, a patch (or other solution) can provide temporary relief. However, for
this system to work effectively, all users must know that the patch is available. Notifying
the public would seem to be the vendor's responsibility and, to be fair, vendors post such
patches to security groups and mailing lists. However, vendors might not always take the
extra step of informing the general public. In many cases, it just isn't cost effective.