Message-ID: <45FC3451.70506@phobos.illtel.denver.co.us>
Date: Sat, 17 Mar 2007 12:32:49 -0600
From: Alex Belits <abelits@...bos.illtel.denver.co.us>
To: Mark Litchfield <Mark@...software.com>
Cc: bugtraq@...urityfocus.com, vulnwatch@...nwatch.org,
	full-disclosure@...ts.netsys.com
Subject: Re: Your Opinion +

Mark Litchfield wrote:

> Consider the Anti-Trust law suits filed against MS by AOL regarding IE 
> and RealNetworks regarding Windows Media Player back in 2003, lets say 
> for discussion, MS now turn around and offer up their 'Security 
> Applications' for free.  You know exactly what is going to happen.

Why do you care? Microsoft is the only OS vendor in a monopoly position, 
and it certainly doesn't need advice from anyone. Nor it would matter, 
considering that Microsoft already bundles malware removal tools, 
provides an interface to port blocking "firewall" functionality in 
Windows, and includes anti-phishing service with its web browser. 
Everyone else can bundle whatever he wants.

> I guess my point is, whilst I appreciate the common comment, what other 
> options are available to an OS vendor.  Offer it up as a free download 
> (not bundled within the OS) allowing the end user to make the decision, 
> or to carry on charging for it ?

You can't make an insecure OS secure by adding "security software" to 
it. You do it by designing OS in a secure manner and by removing 
vulnerabilities. First is an essential part of the OS design, and OS 
design is (or at least should be -- this is why monopolies are 
dangerous) the reason why users want it in the first place. Second is 
usually provided to users for free because the alternative would be 
keeping systems insecure and eventually compromised -- a cause of 
massive embarrassment for the vendor and deterioration of the safety for 
all users (compromised systems are used for attacks that would otherwise 
be impossible).

> Another common theme has been, that the OS should be secure in the first 
> place.  Again I agree with this, but as someone indicated developers 
> schedules are being dictated by their marketing departments with 
> shipment dates, so regardless of their intentions to code securely a 
> vulnerability is likely slip through.

Vulnerabilities are not negated by addition of "security software", so 
this is a moot point.

If vulnerability is found it should be fixed, and if the vendor's 
development process produces too many of them, vendor has to pay (in 
money and developers' time that would be otherwise spend on 
improvements) for more fixing, additional testing and auditing. That 
process will eat into initial savings made by rushed development 
process, so maybe this will force the vendor to revise its development 
policy.

> With regard to third party security solutions outside of the OS vendor, 
> in reality how many new security issues does their software introduce to 
> a fully patched OS.

"Security software" does not increase the security of any computer 
unless it's a replacement of an insecure vendor-provided component or 
product. Those things aren't even usually called "security software" -- 
for example, use of Mozilla-based browser makes Windows desktop more 
secure not because Mozilla-based browsers are designed as "security 
software" but because it allows the user to not use Internet Explorer, 
and it contains less, shorter living or easier to avoid vulnerabilities 
than the product it replaces.

The products that are usually called "security software" usually are in 
the following categories:

1. Data filters/sanitizers. All kinds of "firewalls", email filters, 
on-access virus scanners, etc. that add themselves into some data 
transport mechanism (network connections handling, filesystems/storage, 
OS-specific configuration repository access) and look for known-bad 
signatures and possibly malformed or suspiciously formatted sequences. 
Detection of such potentially harmful data usually results in offending 
data being truncated, corrupted, connection or operation canceled, etc. 
in hope that it will prevent an intrusion.

2. Local intrusion detection and cleanup. Software that runs on 
potentially compromised computers looking for signatures, altered files, 
inconsistent responses from system interfaces and other evidence of 
compromise. Results are reported to the user, and if the symptoms match 
some known piece of malware, software performs some "cleanup" action 
that hopefully removes or deactivates it.

3. Local intrusion mitigation software. Software that runs on 
potentially compromised computers and implements some access policy for 
some system interface (filesystem, network, configuration) that the 
system otherwise would not have. Often "policy" is reduced to asking the 
user to confirm operation, and returning the offending application an 
error if the user denied it. It is assumed that if some malware is 
already running on the computer, user or built-in policy may recognize 
some of actions as being out of the ordinary and prevent malware from 
causing some damage.

This is the closest thing to "making system more secure", however it is 
inadequate replacement for OS design that implements a secure access 
restrictions/policy in the first place, and usually much more difficult 
to implement.

4. Remote intrusion detection software. Software that runs in 
environment expected to be secure, and monitors activity that is 
happening in some other environments to detect possibly compromised 
ones. Though usually a network sniffer running various analysis 
procedures applied to the traffic produced by potentially compromised 
computers, now it can be also implemented as a part of virtualization 
environment -- one virtual machine polices the network, storage and 
device access performed by others running on the same physical host.

5. Backup software. Though not usually recognized as such, it is an 
essential part of any reasonable post-intrusion recovery procedure. 
Again, recently increased popularity of virtualization gave us a more 
convenient kind of backup, recording a full virtual machine state for 
instant rollback to the pre-intrusion condition.

6. Offline intrusion detection and cleanup. Same as #2, but runs is a 
special secure environment while accessing potentially compromised 
storage. Boot CDs and network boot images with virus scanners are in 
this category. Running a virus scanner on a filesystem/storage server 
may be in this category, too, however more sophisticated on-access 
scanner will be in category #1, a filter.

7. Penetration testing software. Imitates attacks (known or potential, 
or produces an attack-like traffic or pattern of access), checks the 
results.

8. Quick recovery to the known-good state. Restores known-good image 
from read-only media while discarding everything else.


None of those things can make an insecure system into a secure one. None 
of them work worse or better if the system it protects is  secure or 
insecure. They merely provide a way for the user to prevent or 
counteract a set of compromise scenarios. Computers are still vulnerable 
to all possible exploits of all security bugs and deficiencies that 
their software has, "security software" merely decreases the probability 
of successful intrusion, and in the case of successful intrusion may 
reduce the consequences (amount of altered, erased or disclosed data, 
control of resources, time the system spent being compromised). Please 
note that in "still vulnerable" I include the situation when a filter 
prevents a certain common virus, worm or exploit from compromising the 
system, yet an altered version of it, exploiting the same vulnerability 
would still pass it and succeed. System is still vulnerable, merely not 
compromised yet.

This has nothing to do with the actual security by design that is based 
on lack of exploitable vulnerabilities and strictly limited scope of 
damage that can be possibly caused by exploits and user errors.

Except for category #3, that is an inadequate crutch for insecure system 
design, OS vendor shouldn't have any advantage over anyone else in 
developing those things. And #3 is a bad thing for the OS vendor to make 
anyway.

-- 
Alex

Powered by blists - more mailing lists