OS Security ( was: Windows Security )

Jiri Baum

Jiri Baum:
> >Anyway, you don't want your office machines compromised, either (both
> >to avoid them being used to attack the factory floor, and for their
> >own sake).

Michael Griffin:
> However, I think you are really not addressing the point I was trying
> to make. You are talking about securing a plant or company, while I am
> talking about trying to secure an individual machine. The former is
> outside the realm of what most people on this list deal with, the
> latter isn't.

The trouble is that authorized access from office machines is likely to be a requirement (or at least desideratum). At that stage you can hope the office machine is secure, of course, but you know very well that it isn't.

I'm not saying securing plant computers in particular is a bad goal. But it would be better to secure computers in general. It's the Right Thing to do. Then plant computers will be secure by default, along with everything else.

The way I'm suggesting is for customers to demand B-level features in their operating systems, both plant and office.

> Let's start with the following assumptions.
...

Reasonable assumptions.

> To address the above questions, I have made the following postulates:

> A) A typical *general purpose* operating system contains a great many
> features which are not required for the above mentioned purposes.
> These features may be such things as media players or internet game
> interfaces.

Yup. (Mind you, many of these features are unnecessary or even undesired in an office machine.)

> B) These features are, under the default installation settings,
> installed regardless of whether they are needed or not.

Perhaps more so in Windows than in some of its competition, but yes.

> E) Some of these uneeded features are potential security problems.

Indeed; but one does not want potential security problems in office machines, either.

> F) The typical person designing and programming the type of equipment
> we are discussing does not either have the knowledge or the time to
> research and solve all the new security problems which come up on a
> daily basis.

Neither do most office system administrators, particularly in small firms where it is not their primary function.

> G) The machine will be installed as a turn-key system in a plant where
> it will run unattended on a continuous basis, and will not be subject
> to the daily patches and modifications which we see in office
> applications.

The same is very likely for office machines, and if it is not the case it would certainly be desired in a great many cases.

> H) There is no one who is going to apply regular patches to the
> operating system for "security" reasons. There is no point in creating
> wild conjectures based on this person being present. Such a person
> simply does not exist at the job site.

Nor in many offices.

> For example - you mentioned "macro viruses" as being a major security
> problem. Macro viruses run by using scripting features present on the
> host computer. If the machine application does not require scripting,
> then scripting can be removed from the installed machine

Certainly - but it would be better for macro viruses not to exist at all.

Removing these from factory-floor computers is a good idea, but doesn't address the underlying problem.

[removing un-needed components]
> So, now the question becomes, how feasible is the above, and how
> easily can it be implemented?

Hmm, for MS Windows third parties have sharply limited ability to create and distribute such an implementation; and near-zero profit potential.

Microsoft itself distributes embedded versions of its products, of course.

For Linux the question is so easy that it is almost trivial; most distros already give very fine-grained control over which components get installed and which get left out. Further control is given by configuration, where a service can be disabled even if it is installed.

Or you could make a new distribution, maybe starting from one that is already close, or else join something like Debian and add limited-version packages (perhaps cut-down versions of packages which are too feature-rich in the original).

Michael Griffin

At 11:24 18/12/01 +1100, Jiri Baum wrote:
<clip>
>The trouble is that authorized access from office machines is likely to
>be a requirement (or at least desideratum). At that stage you can hope
>the office machine is secure, of course, but you know very well that it
>isn't.
>
>I'm not saying securing plant computers in particular is a bad goal.
>But it would be better to secure computers in general. It's the Right
>Thing to do. Then plant computers will be secure by default, along with
>everything else.

I suppose you could also say that world peace and the universal brotherhood of man are also "the Right Thing to do". I was not about to base any of my immediate plans on achieving that either. Rather, I was hoping to focus my efforts on something which was narrow enough in scope to be achieved within my lifetime.

>The way I'm suggesting is for customers to demand B-level features in
>their operating systems, both plant and office.
<clip>

Do you have any particular suggestions on how to achieve that (the B-levels, that is)? I wouldn't want recommend that anyone start demanding "B-level" in their next RFQ unless they have a pretty good idea of how (or even if) it can be done. There is no point in requesting something which I know cannot be delivered, at least not at a price I am willing to pay.

>> F) The typical person designing and programming the type of equipment
>> we are discussing does not either have the knowledge or the time to
>> research and solve all the new security problems which come up on a
>> daily basis.
>
>Neither do most office system administrators, particularly in small
>firms where it is not their primary function.
<clip>

Small firms often have a consultant look after their computer systems on a regular basis. He generally comes by and does repairs, changes, upgrades, patches, etc. Even larger companies are beginning to do this rather than have their own in house staff do everything.
The main reason operating system patches don't get installed though, is instructive. The main reason is that there are so many of them that people don't have time to deal with them. Not just time in terms of manhours, but also in terms of having the real system available to test the effects of the patches on it. This is particularly true for the "patches for the patches" - since the first patch often seems to introduce more problems of its own.
Each patch must be tested for compatability with the critical applications (MRP/ERP, accounting, etc.), and with the network as a whole. Many of these network systems are already barely working as it is. Introducing operating system patches of dubious quailty is usually more of a "threat" to the computing system than a hypothetical virus would be.
I'm trying to avoid this situation in a production enviroment where reliability is more even critical than it is for most manufacturing company's office systems (at least from my point of view).

>> For example - you mentioned "macro viruses" as being a major security
>> problem. Macro viruses run by using scripting features present on the
>> host computer. If the machine application does not require scripting,
>> then scripting can be removed from the installed machine
>
>Certainly - but it would be better for macro viruses not to exist at
>all.
>
>Removing these from factory-floor computers is a good idea, but doesn't
>address the underlying problem.

We're back to the "world peace" arguements here though. "(I)t would be better for (war) not to exist at all", but quite frankly I'm rather delighted that at least my own country hasn't suffered invasion for quite some time now even if it "doesn't address the underlying problem".
Removing scripting from automation system computers may not eliminate the problem of macro viruses from the world as a whole, but a least the production lines will keep running. Surely, that is a worth while goal in itself?

>[removing un-needed components]
>> So, now the question becomes, how feasible is the above, and how
>> easily can it be implemented?
>
>Hmm, for MS Windows third parties have sharply limited ability to
>create and distribute such an implementation; and near-zero profit
>potential.
>
>Microsoft itself distributes embedded versions of its products, of
>course.

Ok, so now we're down to some genuine cases. I didn't have a lot of hope of being able to do much along these lines (removing uneeded features) with Windows. I haven't seen a simple and reliable way of doing this. Of course if anyone else has some suggests of how to do this (remove standard features which are security problems) I am sure a lot of people would be interested.
I don't think the embedded versions of Windows really address the sort of market I am talking about. People seem to be building most custom or low volume production test equipment with the regular office versions of Windows NT or Windows 95/98.

>For Linux the question is so easy that it is almost trivial; most
>distros already give very fine-grained control over which components
>get installed and which get left out. Further control is given by
>configuration, where a service can be disabled even if it is installed.

So, what it would really need is an installation program which would operate on a standard distribution. It would also ideally have an auditing program to check on what someone actually installed.
At the least, if the desired installation can't be automated, then a clear specification of what installation options to pick could be written. This could be along the lines of "use Linux distribution 'A', and install options "1, 2, and 3", but disable configuration options "x, y, and z".

>Or you could make a new distribution, maybe starting from one that is
>already close, or else join something like Debian and add
>limited-version packages (perhaps cut-down versions of packages which
>are too feature-rich in the original).
<clip>

What might be more practical in this case is if someone who was already distributing the Linux software development system we wanted used were to include a suitable Linux "distribution" which goes with it. Or, possibly some credible organisation could offer it (or at least put their name on it). I suppose this latter method could package various useful automation/test equipment development software together, and the "improved security" Linux for the target platform would be just one more item which came with it. This way we would be dealing with a distribution which most potential equipment suppliers would already be familiar with (or at least have heard of).

Jiri Baum

Jiri Baum:
> >I'm not saying securing plant computers in particular is a bad goal.
> >But it would be better to secure computers in general. It's the Right
> >Thing to do. Then plant computers will be secure by default, along
> >with everything else.

Michael Griffin:
> I suppose you could also say that world peace and the universal
> brotherhood of man are also "the Right Thing to do".

Well, true

> >The way I'm suggesting is for customers to demand B-level features in
> >their operating systems, both plant and office.
> <clip>

> Do you have any particular suggestions on how to achieve that (the
> B-levels, that is)? I wouldn't want recommend that anyone start
> demanding "B-level" in their next RFQ unless they have a pretty good
> idea of how (or even if) it can be done.

You can certainly put it in as a desideratum, and preference solutions that have them.

Some B-level features - for instance Mandatory Access Control - are now beginning to appear as options in general-purpose operating systems. They are initial offerings, and there's little experience with them, but that is likely to improve rapidly now that they are becoming widely available.

> >> F) The typical person designing and programming the type of
> >> equipment we are discussing does not either have the knowledge or
> >> the time to research and solve all the new security problems which
> >> come up on a daily basis.

> >Neither do most office system administrators, particularly in small
> >firms where it is not their primary function.
> <clip>

> Small firms often have a consultant look after their computer systems
> on a regular basis.

That makes the situation a lot better, but it would be better still if this wasn't necessary, or at least if it wasn't necessary as often.

...
> We're back to the "world peace" arguements here though. "(I)t would be
> better for (war) not to exist at all", but quite frankly I'm rather
> delighted that at least my own country hasn't suffered invasion for
> quite some time now even if it "doesn't address the underlying
> problem".

As your neighbours to the south found out recently, that can change with shocking speed. The situation is analogous.

> Removing scripting from automation system computers may not eliminate
> the problem of macro viruses from the world as a whole, but a least
> the production lines will keep running. Surely, that is a worth while
> goal in itself?

It is - but if the office machines get compromised, and someone uses them to access the production lines, then those are compromised also. Even with total separation, office machines will probably contain security-sensitive information that can be used in later attacks.

> >[removing un-needed components]
> >> So, now the question becomes, how feasible is the above, and how
> >> easily can it be implemented?

<snip MS discussion - nothing to add>

> >For Linux the question is so easy that it is almost trivial; most
> >distros already give very fine-grained control over which components
> >get installed and which get left out. Further control is given by
> >configuration, where a service can be disabled even if it is
> >installed.

> So, what it would really need is an installation program which would
> operate on a standard distribution.

In Debian, the command "dpkg --set-selections" sets which packages should be installed and which should be removed. Presumably Red Hat has a similar command. (Alternately, you could make a CD with just some packages.)

> It would also ideally have an auditing program to check on what
> someone actually installed.

One can ask for the list of installed packages (dpkg --get-selections) and compare it with a list of what's OK and what's not.

> >Or you could make a new distribution, maybe starting from one that is
> >already close, or else join something like Debian and add
> >limited-version packages (perhaps cut-down versions of packages which
> >are too feature-rich in the original).
> <clip>

> What might be more practical in this case is if someone who was
> already distributing the Linux software development system we wanted
> used were to include a suitable Linux "distribution" which goes with
> it.

That's the other way. However, making it a derivative of Debian (say) would mean that if the user really does need a particular feature, it can just be installed from the regular distribution.

Michael Griffin

<clip>
>> Removing scripting from automation system computers may not eliminate the
>> problem of macro viruses from the world as a whole, but a least the
>> production lines will keep running. Surely, that is a worth while goal in
>> itself?
>
>It is - but if the office machines get compromised, and someone uses them
>to access the production lines, then those are compromised also. Even with
>total separation, office machines will probably contain security-sensitive
>information that can be used in later attacks.
<clip>

I'm starting with the assumption that the office machines cannot be
"trusted". What I want to do is to limit the potential vulnerabilities of
the production machines if something does get inside the company's "maginot
line".

<clip>
>In Debian, the command "dpkg --set-selections" sets which packages should
>be installed and which should be removed. Presumably Red Hat has a similar
>command. (Alternately, you could make a CD with just some packages.)
<clip>
>One can ask for the list of installed packages (dpkg --get-selections) and
>compare it with a list of what's OK and what's not.
<clip>

This sounds promising. I am going to have to investigate this further. I haven't seen any equivalent capability in Windows, which I
suspect is due to the fact that the various parts of Windows tend to be so highly integrated with each other, and are becoming even more so with each sucessive version.
A Linux style solution (not installing features) though would not help me with OEM machines which use Windows. I may have to do some digging into Windows, but I don't have a lot of hope for it at this point. I suspect that the most practical approach with Windows machines is to do what everyone else does - cross my fingers and hope nothing happens.

On another note, Mr. Baum used an analogy about the "Maginot Line" (a common enough reference) and I made a brief addition to it. I don't think either of us wanted everyone else to expand this into a "History of Warfare in the Twentieth Century". Perhaps we could leave off on the history lessons before I am forced to counter attack with quotes from General Slim's "Defeat into Victory".

Jiri Baum

Bob Peterson:
> And really, the worst security problems are not software or hardware but
> people.

> -people who write passwords down on the bottom of their keyboard because
> they are forever being asked to enter them, and they cannot easily
> remember the half-dozen different passwords they need for various
> functions.

This could probably be partly helped by better interface design - some sort of single logon system, so that one password covers everything.

> -disgruntled employees who are authorized access and give that access to
> others.

Mandatory Access Control will cut down a lot of that, especially combined with a physical key. (You can get USB ones these days for <$100 / piece.)

> -people who don't log off when they go to lunch or the bathroom

To a great extent this could be a user-interface issue. Logging off means shutting everything down and then opening it up again. A padlock icon in the toolbar that triggers a passworded screensaver would probably help.

Not much you can do about that, except perhaps make it more convenient, if possible and warranted.

> -people who give out passwords over the phone to an employee who "forgot"
> it
> -peope who have authroized access and use it in unauthorized ways

Again, not much you can do about those.

> My basic practice has been to leave the SCADA systems I supply almost
> totally unsecure.
...
> The end user has to take that responsibility on himself.

That's one approach, of course, but it's not really relevant to this discussion; you make no mention of how the end user is expected to do this, nor, apparently, provide any tools or facilities for it.

Your reasons for it basically boil down to not including security in the requirements analysis. That is a choice, however, not a reason.

Ken Irving

On Wed, Dec 19, 2001 at 08:47:22PM -0500, Michael Griffin wrote:
> At 15:50 19/12/01 +1100, Jiri Baum wrote:
> ...
> >In Debian, the command "dpkg --set-selections" sets which packages
> >should be installed and which should be removed. Presumably Red Hat
> >has a similar command. (Alternately, you could make a CD with just
> >some packages.)
> <clip>
> >One can ask for the list of installed packages (dpkg
> >--get-selections) and compare it with a list of what's OK and what's
> >not.
> <clip>
>
> This sounds promising. I am going to have to investigate this
> further. I haven't seen any equivalent capability in Windows, which I

Not only that, but I haven't seen its equivalent in Linux either. The Debian system is perhaps not the easiest to get up and running at first, but its packaging system covers a lot of ground and makes it very easy to stay updated with *all* the latest bug fixes, holes closures, and miscellaneous improvements, easy to install and remove packages with dependencies all taken care of, and easy to clone the whole system as shown above.

> A Linux style solution (not installing features) though would
> not help me with OEM machines which use Windows. I may have to do some
> digging

Good luck with Windows (honestly , but please note that dpkg is not a Linux thing, it's a Debian thing. RedHat has its package manager, RPM, and it's pretty good and widely used, but Debian is way ahead in simplifying this sort of system management.

One issue that hopefully will get resolved soon is to require digital signatures for Debian packages as the default behavior. I think it is currently possible to do this but not enforced, and many packages aren't currently signed even though the tools are already there to check and respect signatures. That's probably an example of a potential weakness that hasn't yet been exploited by the baddies, but is under (open) discussion and may even get fixed. When that happens it'll get into my systems when I do:

Jiri Baum

> >> Removing scripting from automation system computers may not
> >> eliminate the problem of macro viruses from the world as a whole,
> >> but a least the production lines will keep running. Surely, that is
> >> a worth while goal in itself?

Jiri Baum:
> >It is - but if the office machines get compromised, and someone uses
> >them to access the production lines, then those are compromised also.
> >Even with total separation, office machines will probably contain
> >security-sensitive information that can be used in later attacks.
> <clip>

Michael Griffin:
> I'm starting with the assumption that the office machines cannot be
> "trusted". What I want to do is to limit the potential vulnerabilities
> of the production machines if something does get inside the company's
> "maginot line".

OK, no worries. In that case, though, you cannot allow *any* kind of access from the office machines, no matter how passworded or otherwise verified. The attacker can hijack the connection after the password is given (possibly even covertly, so the authorised user doesn't realise; even just popping up a fake `error' box would probably do the trick).

The problem of fishing for information remains (and whatever else can be done with office machines, like social engineering via forged e-mails).

Michael Griffin

At 01:05 29/12/01 +1100, Jiri Baum wrote:
<clip>
>Michael Griffin:
>> I'm starting with the assumption that the office machines cannot be
>> "trusted". What I want to do is to limit the potential
>> vulnerabilities of the production machines if something does get
>> inside the company's "maginot line".
>
>OK, no worries. In that case, though, you cannot allow *any* kind of
>access from the office machines, no matter how passworded or otherwise
>verified. The attacker can hijack the connection after the password is
>given (possibly even covertly, so the authorised user doesn't realise;
>even just popping up a fake `error' box would probably do the trick).
<clip>

I suppose this depends upon what you consider "access" to be, and what degree of security is desired. To deal with the second issue first, it is not feasible to make any system of the sort we are talking about completely secure. If a knowledgable person is going to make a concerted effort to break into that particular computer, I can only assume that they will eventually succeed. These computers are part of a production line, so genuine physical security is of course also impossible.

However, I think it is desirable and feasible to make a system resistant to the typical virus and worm incidents which target desk-top systems. We've already discussed several approaches to that, including removing and disabling unneeded features which could present a security concern. An operating system which allows a greater degree of configuration is of help in these cases.

The degree of remote access allowed has a major effect upon security. Logging test results to a network database would seem to present a low risk.
E-mail, embedded web servers, and remote log-in would probably be higher risk. These "higher risk" methods are in many cases also of low value, and so can usually be left out of the system. If the use of a "higher risk" method is desired (e.g. an embedded web server), the risks can be weighed against the benefits, and the same approach can (if possible) be taken to limit the active features to those actually needed.

Jiri Baum

Jiri Baum:
> >In that case, though, you cannot allow *any* kind of access from the
> >office machines, no matter how passworded or otherwise verified. The
> >attacker can hijack the connection after the password is given

Michael Griffin:
> I suppose this depends upon what you consider "access" to be, and what
> degree of security is desired. To deal with the second issue first, it is
> not feasible to make any system of the sort we are talking about
> completely secure.

Certainly - but one should make it as difficult for them as possible; and there is a great difference between `can be broken with concerted effort' and `can be broken by a random teenager with too much free time'.

> The degree of remote access allowed has a major effect upon security.
> Logging test results to a network database would seem to present a low
> risk.

Obviously; however, with the trend towards integration with Enterprise Systems, the desired degree of remote access is likely to be greater.

And even logging to a database presents risks (can the database response overrun a buffer?).

These, however, are precisely some of the advantages of PCs over PLCs (or PC-like features in PLCs, as the case may be).

> These "higher risk" methods are in many cases also of low value, and so
> can usually be left out of the system. If the use of a "higher risk"
> method is desired (e.g. an embedded web server), the risks can be weighed
> against the benefits, and the same approach can (if possible) be taken to
> limit the active features to those actually needed.

The trouble is that with the office machine insecure, this is likely to be extremely difficult, because the factory floor machine (or its firewall) can never be sure whether it's talking to an authorized person or to an attacker which has taken over the office machine.

It's not (just) weaknesses; it's the desired features, being used for ill.