J
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).
Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
> >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).
Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools