Windows Security (was: Virus warning)

G
Ralph,

First, let me say that I agree with your assessment that firewalls are necessary components of an overall computer security strategy, if insufficient in themselves to provide total security.

However, I disagree with your interpretation of the Maginot Line analogy...

> > > Firewalls are the Maginot lines of the Internet.

[snip]

> However, the firewall's purpose is not to
eliminate all security risks related to the Internet. The firewall's purpose
is to prevent
specific kinds of communications [across a network boundary] from occuring. <

Nor was the Maginot Line intended to eliminate all the possible threats to the integrity of a sovereign nation. It was designed to prevent the transport of a particular threat across a particular boundary.

> Firewalls won't stop denial of service
attacks for instance. [snip] Firewalls won't address internal security
problems such as disgruntled ex-employees with old accounts that are never
disabled. <

Just as the Maginot Line (or any other perimeter defense) won't prevent a run on the National Bank or a coup d'etat by disaffected military veterans. If your overall security must encompass these threats, you must put into place
other, additional measures: rational monetary policy, good internal intelligence, social and political structures that promote loyalty among the police...

I see the failure of the Maginot Line as a useful object lesson, on par with the Polish Cavalry's failure against the German tank corps and other well-known attempts to meet a new threat with old technology.

The term "firewall" is itself a metaphor, and doesn't imply any specify mechanism for implementing the protections it provides. What does your firewall do? It's not as if firewall technology isn't evolving to meet new threats. (I guarantee that if you're still using the same firewall setup today that you thought was adequate three years ago, then you are vulnerable today to threats you didn't know about then.)

My point is that we should constantly re-assess our solutions as the problem - or even just our understanding of it - changes. After all, we're engineers, that's what we do; design and deploy solutions to the problems we know or anticipate, then evolve the solutions to deal with whatever comes up that we didn't see coming.

Regards,

Greg Goodman
Chiron Consulting
 
On Wed, Dec 19, 2001 at 08:47:24PM -0500, Michael Griffin wrote:
> At 21:45 18/12/01 -0500, Ranjan Acharya wrote:
> <clip>
> >However, Linux is not immune to security flaws. Recently a problem
> >was discovered in the wu-ftp client that runs under all the various
> >distributions on Linux (Caldera, Red Hat, SuSe and so on).
> <clip>
>
> I heard about this recently. This was one of the things that
> reinforced my thoughts about limiting uneeded features. The version of
> this story that I read though said that this particular ftp client was
> only used on some Linux distributions (there are others available
> which some people preferred), and only in some versions. Also, many of
> the people who had this package didn't install it, and so weren't
> affected.

wu-ftp has had alerts and fixes for years, perhaps one of the most visible examples of the attack-patch situation. Other examples include bind and sendmail, and an endless stream of others on any platform you can think of. It is important to be aware of exploits and weaknesses if you're using these things, and to apply the fixes as they become available.

Most folks nowadays eschew ftp and telnet altogether and use ssh (secure shell) of one version or another. There are free clients available for Windows (e.g., Putty) so there's little excuse to be running ftp on machines that aren't specifically needed for serving that protocol.

> In other words, this wasn't something that affected every
> Linux system in existence, only some. What this tells me is if I don't
> need (for
> example) ftp, then if I don't install it I won't have an ftp problem in the
> event that another problem turns up in future. This same principle could be
> applied to other features. I don't have a list of what these features may be
> at this point, but it sounds like a promising approach to limit the amount
> of software maintenance needed.

Exactly.

> This really isn't much different from other maintenance
> problems. For example, we have several lines where the builder
> installed ventilation fans on all the electrical enclosures. We found
> ourselves changing a lot of filters until we looked at whether the
> enclosures actually needed fans. It ...
> By the same token, I would like to avoid installing software
> patches to fix features we don't even need.

As to knowing what needs to be patched, an advantage of having the source available for perusal is that it's possible (if not trivial) to grep the sources for what's on your system to look for things, perhaps a particular string that might flag a bug or trojan horse. I read (1) of a (probably untrue?) claim by someone in India that Al Qaeda had planted trojan code in Windows XP... Your assurance that this isn't the case (besides just not believing it) can *only* come from Microsoft, since no one else can view the actual code. I wonder what they'll say?

Ken

--
Ken Irving <[email protected]>

(1) http://lwn.net/2001/1220/security.php3

 
C
It's also important to note that very, very, few of the Linux vulnerabilities have been succesfully exploited, most being found by code inspection by white hats. I can't think of any that caused notable harm or disruption before they have been fixed and none that have caused the enormous disruption and expense of even one of the MS "virus of the week" staples that have run rampant for years now. The only MS holes we know about are discovered at great cost after they are exploited. My greatest concern is that the next terrorist action may well be a Windows virus that shuts down government and the military as well as utilities and industry. We have seen mostly "funny" viruses with the emphasis on reproduction rather than destruction. If someone skilled sets out to really destroy, it will be disasterous. The homogenous monopoly platform model is absolutely the worst case for security, without question. And it's insanity to keep it and furtively hope for the best against the dismal track record. Diversity to break the chain of infection is crucial, but has not recieved serious consideration. It will take a disaster before they "get it". And the USA is way behind Europe in this realization. Money is still more important than national security.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net. Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
B
[email protected] writes:

> While the brief history of the Maginot line was very interesting it
> does not address the essential flaw in claiming that modern firewalls
> are equivalent to the Maginot line. I must disagree with this
> assertion very strongly.
>
> The Maginot Line's purpose was to prevent an enemy from acheiving a
> successful invasion. It was an incompetent solution for that purpose
> as was pointe out.

More on the Maginot line.

The Maginot line was actually very effective. It was designed to prevent a head on attack by the Germans, which it did. Unfortunately, the French ran out of money to complete it and so they relied on the Ardenne Forest to complete the system of fortifications.

Guess where the germans chose to attack?

The same thing happens with computer security (or for that matter any security system). Those who wish to breach your security will do so at the weakest point. All the Maginot line did was force the Germans to attack the French where they were weak. Thats what all security systems end up doing.

continuing the analogy a bit more - even though the maginot line was incomplete, the french had large armored forces that could have been used to cover the gap in the maginot line, and might well have been able to stop the germans or discourage them from attacking in the first place. instead they chose to disperse their armored forces and ended up using them as little more than mobile pillboxes.

we have all kinds of techniques we can use to increase the level of security of our contol systems. just because one thing does not work does not mean that a combination of ideas cannot effectively secure our systems. However, no matter what, security systems will forever need improvements, updates, and patches. Its just the nature of the beast.

the history of man is filled with people and nations (many now all but
forgotten) who thought they could be secure by doing "X", but found out the hard way that the enemy found "Y" could be used to breach "X". Think of the example of castles versus cannon! castles were extraordinarily effective for defensive purposes before the cannon. most required only a few full time defenders (in some cases a dozen or less), yet were very secure until the cannon came along.

I think it is the height of ego to suggest that some new form of access control, procedure, or piece of software will change this situation any.

Bob Peterson
 
A
For Instrumentation, Automation, Control, Advanced process Controls, MES or other solutions:

The truth is that you will have a system which is going to be weak for some period of time. This could be hacked, passwords cracked, logic's changed and so on.

This is so because, you may not be able to load patches, stop your process or take shutdowns just for upgrading the security patches. Note in the web world, sometimes there could be 2 patches in a day or more.

Even in the case of redundant systems, in several cases, you may not be able to upgrade the secondary, then take the secondary on line, put down the primary and upgrade it. The risk of shutting down the system may be very high and there might be some other skepticism. Plus statutory or plant procedure may require you to carry out an Factory Acceptance type Test of your system in case of an upgrade.

You need to put a server between your automation networks and your plant networks. let us call this the gateway server. You need to upgrade this server regularly Have procedures and systems in place to handle problems.

Please contact ISA Maharashtra region ([email protected]) for a paper on security issues for web based automation systems with focus on protection techniques.

Anand K Iyer
 
D

DAVCO Automation

This is a product of scale. As Linux gains in usage so too will it start to push down to the "casual" user, whos living does not come from setting up software and then you too will experience all of the vulnerabilities of software setup incorrectly.

Microsoft is so prevelant and therfor has many casuall users who do not know the first thing about security and therfor vulnerabilities which are well documented are exploited.

Many patches are released and even very knowledgable users do not apply them, there is nothing that can be done about this.

When Linux is more than a fad and by that I mean when it reaches meaningfull numbers, then we shall compare the apples and apples, but until then as always .....quit throwing stones.

Dave
 
M

Michael Griffin

To continue on with the theme of security problems with operating systems, I read an interesting story on the CBC News web site about security holes in Windows XP. I won't repeat the entire news story, but I'll briefly quote the salient points:

"The FBI is warning consumers to take extra steps beyond those recommended by Microsoft Corp. to protect against potential hacking of the newest Windows software, which was marketed as the most secure ever."
"Microsoft's Web site offers a free software patch to correct major flaws in the Windows XP operating system. But the FBI advises consumers to not only install the patch but also disable the product's "universal plug and play" features."

Also:
"Security experts say disabling the feature could protect against similar flaws found in the future."

And in conclusion:
"Officials expressed fears of hacker attacks against Web sites and federal agencies during the Christmas holidays from computers running unprotected versions of Windows."

There were a number of other points raised in the news story, but I am sure that anyone who wants more details about this particular incident can read about it from any of a number of suitable news sources.

http://www.cbc.ca/cgi-bin/templates/view.cgi?/news/2001/12/24/windowsxp_patch011224

What I found interesting is that the American police felt that downloading the recommended patch was not good enough, and were asking people to disable certain features of the operating system. Note the statement "security experts say disabling the feature could protect against similar flaws found in the future". This solution is similar to the discussions we have been having on this general problem.


Something which hasn't been discussed so far is the business aspects of the security issue. Simply put, who is responsible for correcting the security problems with a PC based system during its warranty period?

The reason this could be considered a warranty issue is that the operating system supplied was defective (hence the need for the patch), and this is really no different from any other defective machine component. If the system was sold as being able to communicate (e.g. for reporting information, remote service, or other such purposes), then the customer could be justified in assuming the system designers have taken care in ensuring the system is reasonably secure.

I have the feeling that most customers have just been assuming this responsibility themselves. However, they may stop being willing to do this any longer if the number of PCs increases and the work involved becomes significant. In addition, many companies have traditionally had IT staffs on site to look after their office computer systems, and these people have often been willing to help out with these problems. This line of support though will in many cases disappear in future as these IT staffs are cut back or eliminated through out-sourcing.

Any comments?


**********************
Michael Griffin
London, Ont. Canada
**********************

 
C
List Manager wrote:
> ---------- Forwarded message ----------
> From: "DAVCO Automation" <[email protected]>
>
> This is a product of scale. As Linux gains in usage so too will it
> start to push down to the "casual" user, whos living does not come
> from setting up software and then you too will experience all of the
> vulnerabilities of software setup incorrectly.

It's not the user's fault. You can't require perfect users. And studies have shown that Linux users are at least as lax as MS users about security. Probably more so, because there is no tangible threat.

> Microsoft is so prevelant and therfor has many casuall users who do
> not know the first thing about security and therfor vulnerabilities
> which are well documented are exploited.

This is the real world, software should be written for it, not nirvana. I keep hearing that as the party line. If you consider webservers where the market shares are approximately equal, the security disparity remains which somewhat destroys that argument. Desktops cannot be compared without taking numbers into account but when you do, I'm fairly sure the picture won't change. It's a fact of life in the Linux community that if there was a problem you'ld certainly hear about it on slashdot at high volume.

> Many patches are released and even very knowledgable users do not
> apply them, there is nothing that can be done about this.

Many of the bigger problems lately do not exploit vulnerabilities or bugs. They exploit _features_ that are intended to be there. Many MS features are very ill advised from a security standpoint but are there because they provide well loved or strategic functionality. The epidemic continues because they are not willing to lose these features.

I'll excuse them their patchable bugs and vulnerabilities, but there sure are a lot of them.

> When Linux is more than a fad and by that I mean when it reaches
> meaningfull numbers, then we shall compare the apples and apples, but
> until then as always .....quit throwing stones.

As I said, where they have comparable market share the disparity remains. If you find anything there that is non-factual, I will gladly apologize. Especially if you are willing to stop parroting Microsoft FUD. I was not throwing stones, it's _obvious_ that everyone running the same software is the best possible case for virus propagation. And now that chicken is coming home to roost.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net. Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
M
> Something which hasn't been discussed so far is the
> business aspects of the security issue. Simply put, who is
> responsible for correcting the security problems with a PC
> based system during its warranty period?

The license states that Microsoft will not take responsibility for squat, thus the responsibility falls on the licensee. They
should consider themselves lucky that Microsoft is even putting out patches, as the license does not say that they will fix bugs.

>
> The reason this could be considered a warranty issue is that
> the operating system supplied was defective (hence the need for
> the patch), and this is really no different from any other
> defective machine component. If the system was sold as being
> able to communicate (e.g. for reporting information, remote
> service, or other such purposes), then the customer
> could be justified in assuming the system designers have taken care in
> ensuring the system is reasonably secure.

You should not assume that, as it is not what's agreed to under the license. The software works until someone breaches security and breaks it, but they are under no obligation to provide a secure system.

>
> I have the feeling that most customers have just been
> assuming this responsibility themselves. However, they may
> stop being willing to do this any longer if the number of
> PCs increases and the work involved becomes
> significant.

They will quit when they find another vendor that is willing to agree to provide a secure system, or find one that does provide a secure system (even if they don't guarantee it).
That's why a lot of us like Linux.

Mark
Any opinions expressed in this message are not necessarily those of the company.
 
C
Hi Micheal

My take on the whole thing is that, logically, these concerns deserve at least a little consideration when selecting an OS FOR AUTOMATION PURPOSES. Yet it seems that this can not and will not be considered. The current default offering is perhaps the least suited to, and least affected by, the needs of the automation market. And as time goes on this initial choice becomes less and less suitable, in fact is moving in directions totally antagonistic to what is needed. Even DOS with all it's infelicities was and is a better choice for many purposes and this is reflected in the fact that it is still widely used and some new tools are even being written for it. It seems to me that the cost/benefit analysis is way, way, out of whack and getting worse and yet, the majors keep charging on in the same direction.

A good OS for automation should be modular:

For at least 70% of what we do, why are we even considering security problems and viruses and such. It's purely excess baggage carried along with a monolithic bundled OS. If you could pare it down to only what is relevent to the job at hand, problem solved. This is the _best_ way to address these problems and has a huge payback in efficiency, speed robustness, and simplicity. These are factors that _do_ matter in automation. A very high percentage of the default choice, including a great many of the largest problem areas are totally irrelevent to automation projects. But, bundling is sacred.

A good OS for automation should support the _we_ need.

We don't need frantic churn and dll hell. We don't need huge blasts of buggy new office and consumer features. The only new features for quite a while from the legacy system that have not been detrimental have been a long needed improvement in reliability and stability. These come at the cost of tremendous effort upgrading, rewriting recertifying and even replacing hardware to keep pace with changes that add little of nothing to the functionality we need. We could use much less chaos. At the same time, support for serial ports, ISA cards, and direct hardware awareness in general is being deprecated. Indeed, even local applications support will be discouraged as they move to an ASP model. Where does this leave us? We _need_ those things and use them every day. We are simply being written off.

In fact, we could strongly benefit from better hardware access and legacy hardware support, The ability to tailor the OS to our needs, control obsolecense, support long equipment lifetimes and lower costs drastically. Bug fixing and support should not end in a year or two. A customer is not well served when they can't get support for a 3 year old system simply because the OS has been obsoleted to generate more revenue.

Why doesn't any of this matter? What is so good about the legacy system that so many negatives are tolerated or ignored? Especially when there is a proven, rock solid alternative that is infinitely more aligned with the kind of work that is done in automation and it can even be influenced to align more closely to meet our needs. Expecially when we are a technical audience that can easily handle the change and most have been through several such changes? Why continue in such a clearly wrong direection?

Please, what part of this makes sense?

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net. Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
M

Michael Griffin

At 15:21 30/12/01 -0500, Blunier, Mark wrote:
<clip>
>> Something which hasn't been discussed so far is the business
>> aspects of the security issue. Simply put, who is responsible for
>> correcting the security problems with a PC based system during its
>> warranty period?
>
>The license states that Microsoft will not take responsibility for
>squat, thus the responsibility falls on the licensee. They should
>consider themselves lucky that Microsoft is even putting out patches,
>as the license does not say that they will fix bugs.
<clip>

No, I wasn't suggesting that Microsoft is responsible for the warranty, I was suggesting that the company which built the machine (and which installed the software) would be held responsible for testing and installing whatever patches or fixes or whatever other measures are necessary as part of the machine or system warranty. If I buy a machine or system from you, I am not interested in whatever problems you may have with
*your* suppliers. My contract is with *you*, not with Microsoft or any other software company. If your suppliers won't support you adequately, well I may feel sympathetic but really, that is your problem not mine.

(I not trying to lecture Mr. Blunier by saying "you", but rather I am addressing the general audience.)


The question really comes down to "what was written in the contract"? If this type of problem becomes a big enough issue in future, I suspect that customers will be reviewing the contract language to make sure it is covered. I've seen at least one case recently where the (new) motherboard had to be replaced with a different model because of cascading conflicts between Windows version/VB/board drivers. The actual cost of the motherboard was small though compared to the engineering manhours spent on sorting it all out.

This actual example was part of a new installation so there was no question that the supplier had to assume the cost to get it working. Now suppose a project was undertaken in which a certain level of security was specified or promised. Suppose in addition, that during the warranty period, it was discovered that this level of security was not in fact delivered, due to defective software in the operating system or elsewhere. The customer would be asking the system supplier not Microsoft (or any other software
company) to take some appropriate corrective action.

If you are confident that the software you are using (of whatever
type) is of good quality, and that you can install and configure it in a manner which makes these sorts of problems unlikely, then you shouldn't have any problems standing behind whatever software you supplied with the system. If you are not confident, and are only using it because "it was in the customer spec" then you may need to review just what you may be committing yourself to.

If a customer discovers they have a choice between meeting the spec
(security) or following a "standard" they have set, they need to review whether insisting upon their standard is relieving their suppliers of responsibilities which the customer wants them to retain. We try to avoid this sort of problem with hardware specs by making it the supplier's responsibility to propose an alternative if the specified hardware is not suited to the application. Some sort of similar thought would seem to be needed for software.


**********************
Michael Griffin
London, Ont. Canada
**********************

 
Top