Slashdot Mirror
Computer Security Criteria
Rolf Marvin Bøe Lindgren writes: "For most human endeavors that involve some sort of risk, there are powerful, recognized public interest groups or even government-appointed organizations that investigate and analyze dangers, prescribe guidelines, determine criteria for acceptable risk, etc. This does not seem to be the case for software! I work for a ship classification company. The purpose of such companies are, very simply put, to determine how safe seagoing vessels are, for instance in order that insurance companies can decide insurance premiums. There are, needless to say, numerous conventions and special interest groups to determine safety at sea. That is, as far as I know (and I would very much like to be proven wrong), except the computer systems that the ships use. there are restrictions, laws and regulations involved in just about any object that goes into a ship except the computer system. Everybody seems to know, for instance, that UNIX is safer that Windows, but there are no safety, reliability or security criteria established by any recognized authority that can be used to defend one computer system over another."
"Now, I could ask Slashdot how to go about to form a recognized body, but I have access to competence in that particular matter. What I would rather like to know, is this:
- What might a set of safety criteria be like (I am just now most interested in criteria for computer systems that would address such issues as vulnerability to worms, viruses and crackers)?
- How should one go about to find competent and interested people who would like to be part of a body like I describe, or consultants to one?
Um, hate to break it to you, but how the hell do you hack a system that's on a ship and self contained? everyone's talking about virus this and worm that, who gives a crap? my guess is that the ship's navigation systems are secluded from anything that would have outside access.
what i'm guessing he wants to know is something more along the lines of this.Windows NT cripples US Navy Cruiser
in which case, he's really asking which software/OS is the least likely to puke and leave you up a creek without a paddle.
Later the EU produced their Green book which looked at availability as well, this is kind of good for information systems but it doesn't really cover real-time control systems.
A long time ago, I worked on real-time control systems. We divided our systems into control/measurement, supervisory and at the top, information systems. At the lowest level, we are talking hard real-time and simple enough to be very reliable. They had to be as they were typically sitting by a man-sized chemistry set. The supervisory systems gave the pretty interfaces, they could crash, but generally they didn't. These were for control rooms, and whilst bypassing them was possible, it wasn't easy. The top level system ran all kinds of complicated software applictions that could and would occassionally crash. Apart from the crudest electrical standards for the stuff in the plant and the control room, there were no evaluation criteria.
Sure Windoze apps have buffer overflow holes like [insert good analogy here], but when was the last time your WinVERSION came installed with a plaintext remote login server? Or have you seen Windoze setup with directory services exporting crackable password hashes? .. Unix is safer in many respects (especially to the scheduled-to-be-obsolete Win95/98/ME series), but I don't know that it's a cold statement of fact to say everyone knows that UNIX is safer than Windows. Depends on the attack vector.
If you need text styles to communicate then you don't have a message.
The MacOS running WebStar as a server has never been exploited.
In fact in the entire securityfocus (bugtraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac with WebStar.
I am not talking about BSD derived MacOS X (which already had a couple of exploits) I am talking about Mac OS 9 and earlier.
Why is is hack proof? These reasons
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT
2> No Root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root their is no false sense of security.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits.
4> Stack return address positioned in safer location than intel. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac places return address infornt of where the buffer would overrun. Much safer.
5 : Macs running Webstar have ability to only run CGI placed in correct lodirectoy cation and correctly file typed.
6> Macs never run code ever merely based on how a file is named. ",exe" suffixes mean nothing. For example the file type is 4 characters of user-invisible attributes, along wiht many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For ecxample file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable of creating an executable file. the file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually.. TOTAL security.
7> There are less macs, though there are huge cash prizes for craking into a MacOS based WebStar server. Less macs means less hacvker interest, butthere are millions of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc).
8> MacOS source not available traditionally, except within apple, similar to Microsoft source availability to its summer interns and such, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
I think its quite amusing that there are over 200 or 300 known vulenerabilities in RedHat over the years and not one MacOS remote exploit hack.
I recall that a while ago some navy ships were stopped dead in the water due to computer failure, so there are legitimate concerns. Most ships have a large number of fallback systems - notably crew - that can recover from most problems.
Large ships also benefit from a reasonable physical security structure - limited bridge and engine room access for crew - that help computer security
In light of a natural physical isolation, limiting the net access of the navigation computers is a natural and effective security boost.
Most of the 'essential' computer systems that are currently used are not OS based, but embedded. It would be silly to worry about the electronic fuel pump in your car getting a worm. These embedded systems are often virus proof because they use ROM program space. Any bugs are the result of programmer error and insuficient testing
So, I suspect that only high-level systems like navigation are vulerable to worms. Now, let's take a look at possible damage
Massive failures can be caused by hardware, so there must be a backup system regardless of the software that you choose
The same redundant systems can also be used to keep the master system honest
In general good policy and management is more important that what software is used.
Maybe now that companies are offering hacker insurance some standards and guidelines will develop?
On the other hand...when has the computer industry ever mirror any real world industry? We still don't have the equivalent of the Consumer Product Safety Commission nor is there product liability, recalls, or defect-related lawsuits.
If there were, Microsoft would make the Ford/Firestone fiasco look like nothing.
- JoeShmoe
.
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
It all depends on the industry in question. Take as an example, light bulbs. When you buy a lightbulb for you bathroom light, no one really cares. But when you buy a light bulb for your car headlight, you start running into safety regulations. And when you buy a light bulb for your left airplane wing, the FAA is going to be breathing down your neck.
I help build software for invasive diagnostic medical devices. The FDA (and similar organizations for other nations) is very concerned about the software we use. They don't have a checklist of brands, makes and models of software, since that's not the nature of software. But they do audit our development process. ISO compliance is easy. FDA compliance is hard.
For our next project, some boneheads decided on Win2K and "embedded" Win2K. I personally think the decision is stupid. But it probably won't affect the final quality of the device. Why? Because it won't be a stock Win2K, it will be the embedded version, stripped of everything we don't need. We will be in charge of the hardware it runs on. It will be tested under rigorous protocols. Etc.
The FDA doesn't care that it will have Windows on it. But they will care that it operates safely. That means it can't crash while diagnosing a live patient.
A Government Is a Body of People, Usually Notably Ungoverned
I would venture to guess myself that software is very hard to regulate in a normal sense. On complex pieces of code (KISS standard aside) it is nigh impossible to completely prevent bugs 100%of the time. That's the ideal, but that's why we call it ideal.
If a bug occurred in a very unique situation, and it took 20 years for that situation to come about and it caused just one death, people would still ask, "Why wasn't anything done to prevent this?" Something was done (hopefully), and standards and regulations help, but in the end that's pretty much all you can do.
I don't think he's asking as much about viruses or hackers in this case, but those are also valid questions. I tend to believe what is stated downstairs in this argument -- I've seen Unix systems that were wide open and Windows Boxes sealed tighter than a drum, and it's up to the admin. I'm not really sure if there's a test or anything that sysadmins must pass to become licensed sysadmins, but if there isn't (and I'm not talking about certification) there should be one, at least as far as sensitive data like this is concerned.
Also, a real life situation when computer software caused multiple deaths was in the case of the London Ambulance Service, which used a very poorly constructed computer system and was directly linked to 20 or 30 deaths (due to late ambulances) in the few days it was active.
Here is another clue I got today from my uni lecturer. If you wanted to run a secure web server, would you run it on NT, Linux, Solaris or the Mac?
*Up go hands of Linux advocates*
Answer: Mac because it is the least available operating system and as such fewer attacks have been created for it, even if there are hypothetically more bugs. As such, you would be less likely to suffer a problem, all else being equal
Back to the article, would a measurement take into account this type of situation? Does Mac get a high rating for low rate of incidents or a low rating because it (probably) has more bugs than Linux. Open question
To be perfectly honest, is the computer on a ship going to be networked externally? Maybe the control systems on board are linked by a network, but surely there is no need for vital systems to be connected to the outside world?
If the ship needs a internal network connected to an open network, then it should be entirelly physically separate to the control systems. No firewalls, no fancy security measures. Just no route between the two.
More of an issue is software reliability and stability. I won't get into the linux/windows argument, but generally, a more stable, stripped down system can be easily achieved with linux. In windows, you run the whole OS, no two ways about it, even if it just adds to instability and problems.
Generally, on essential computer systems, such as those on planes, radar, life support systems, and sattelites, are as simple as possible, and undergo rigerous testing. The development is often frozen early on because of this, resulting in reduced features, but better overall performance. It can take several years for changes to propagate throught the system... this can be annoying if it is as simple as a GUI change (say, one display needs to be frequently accessed, but requires several button presses, where another, rarely used display has instant access off the yoke).
Hardware reliability could be a problem as well - though I should imagine these systems are ready built by people who know what they are doing. I wouldn't trust off the shelf boxes and bog standard cat 5 linking them.
Redundant systems are probably a very good idea - as is some form of power conditioning and UPS system, as ships power may not be the best.
There is a lot to consider, but I think you may just as well turn to someone who has experience with aviation computers as well as someone who knows a lot about closed network security.
And imagine.... maybe the dodgy oil tanker plot in hackers could come true...
Click on 'classifications', then try to use any of the links on the left, register of vessels and such. The link for that is file:///registerofvessels. Needless to say, that link doesn't work too well on a public internet.
MacOS is safer than Linux OR windows.
:
Consulting self apointed experts have nothing to do with reality of waht is safest.
Use Bugtraq to make your decision based on historical fact.
The MacOS running WebStar as a server has never been exploited.
In fact in the entire securityfocus (bugtraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac with WebStar.
I am not talking about BSD derived MacOS X (which already had a couple of exploits) I am talking about Mac OS 9 and earlier.
Why is is hack proof? These reasons
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT
2> No Root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root their is no false sense of security.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits.
4> Stack return address positioned in safer location than intel. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac places return address infornt of where the buffer would overrun. Much safer.
5 : Macs running Webstar have ability to only run CGI placed in correct lodirectoy cation and correctly file typed.
6> Macs never run code ever merely based on how a file is named. ",exe" suffixes mean nothing. For example the file type is 4 characters of user-invisible attributes, along wiht many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For ecxample file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable of creating an executable file. the file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually.. TOTAL security.
7> There are less macs, though there are huge cash prizes for craking into a MacOS based WebStar server. Less macs means less hacvker interest, butthere are millions of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc).
8> MacOS source not available traditionally, except within apple, similar to Microsoft source availability to its summer interns and such, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
I think its quite amusing that there are over 200 or 300 known vulenerabilities in RedHat over the years and not one MacOS remote exploit hack.
gears and software analogy off are not similar... programs can recurse and programs can generae code and programs can self replicate. In fact a computer can control a servo arm to play ping pong. playing ping pong with prure analog machinery is probably impossible.
The VTOL aircraft Osprey has killed US Marines due to a software error which became occurred in reponse to a hardware problem:
/
http://www.cnn.com/2001/US/04/05/arms.osprey.02
Send lawyers, guns, and money. Dad, get me out of this.
IEC 61508: "Functional safety of electrical/electronic/programmable electronic safety-related systems".
This standard, which also applies to software (see 61508-3: Software requirements), defines some very stringent requirements for systems that have anything to do with safety, i.e. where a failure of the system could endanger life.
See the IEC's website for more...
Have you tried British Standard BS7799? I think it has been turned into an ISO standard (or is underway). It defines how to turn your organisation into a secure/reliable environment - and more importantly how to prove that it is. It takes into account the fact that systems change, and that they are not reliable - and helps you work around/knock down the risks to a level you are comfortable with. It is used mainly for companies - but I don't see why it couldn't be used for any organisation (read: ship-board network/control system). In fact, get in touch with them on http://www.bsi-global.com and see if they would be interested in defining a sea-borne computing standard (they do that kind of thing with private firms as long as the standard becomes public domain...).
Alternatively, call a manufacturing network supplier. Think about the kind of reliability that Ford or GM requires on the assembly line - they don't allow any crashes! (har har har) There are (as usual) several competing standards which could be converted to nautical use.
Pimping my Karma Whore since 1847.
Computers for main functions (propulsion, steering, cargo) in a ship have been in use since the mid seventies, and although lagging somewhat behind in the beginning when it came to Rule coverage, all major Shipping Classification Societies today have Rules which cover above use of computers onboard ships. This relates both to hardware and software. E.g.:For DNV (Det Norske Veritas) see Rules Pt.4 Ch.9 (Instrumentation and Automation) Sec.4. This is 2,5 pages of what experience have taught us are the most important aspect concerning computers onboard. However, everything else in Pt.4 Ch.9 concerns computers as well as other technology platforms, the Rules are written to be as technology independent as possible. The gradual increase due to expense Considerations in the use of PC's as workstations, , are something we haven't taken lightly. The hardware needs to prove itself by going through environmental/EMC testing (See Rules Pt.4. Ch.9 Sec.5 and Standards for Certification 2.4), and the software is tested by Approval Test of Application Software, where normal operation as well as reaction to most probable system failures are tested. Admittedly the first Windows versions were not secure, but today's versions are mostly acceptable, that is if you know which precautions to take. Of great concern is young eager software designers who haven`t learned their lessons and read necessary safety documentation before diving into the design phase. It seems DNV as a Classification Society have a similar problem. We would not object if you do some more homework and then revert with your findings! By the way, DNV does have a group working with software analysis as well, as far as I know they are mostly used in the consulting role, for manufacturers developing extremely safety critical systems. One last information: DNV consists of 5400 individual spread all around the world, all trying their best to fulfil our intentions of keeping our customers on the right track with regard to safety matters.