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?
Have you looked at any of the work done by SANS (http://www.sans.org) or NIST (which is not necessarily what you're looking for, but in the area of providing guidance, http://www.nist.gov)?
SANS has been publishing a series of "consensus" documents, asking for feedback from people on topics such as securing Windows and Unix versions. They've also put together a working group (pay to join).
If you have looked at these sources, I would be interested to hear how they do or do not fit in to what the author of the original question is looking for.
well, have you checked out these things?
http://www.commoncriteria.org/
http://csrc.nist.gov/cc/pp/pplist.htm
Sorry for not making a huge long rambling post, but you really should check out the Risks Digest
--xPhase
The following sentence is TRUE. The previous sentence is FALSE.
Closest is the international Common Criteria . It's the indirect descendent of the old military orange book (you know, C2 certified, etc.). The attempt is to come up with multiple standards for each security critical component. The components are evaluated against the standard. A higher rating means they meet the standard to a stricter engineering criteria.
Some sample standards (or "Protection Profiles") include proxy and packet filtering firewalls.
My sense is the folks overseeing the Common Criteria would like industry groups to sponsor Protection Profile development. For example, banks could come up with profiles for wire transfer components, ATMs, etc. The shipping industry could be another.
BTW, if you visit the Website, there is an interesting line of Common Criteria-branded clothing, for the geek who has everything!
The FAA has well-known procedures in place for certifying HW and SW for safety. Look up DO-178B, for instance.
It'd be almost trivial for the shipbuilding industry to adapt them to their somewhat lower-risk environment.
--Blair
There is one answer... the US government has published a civilian version of a process that the DoD has been using for a while. It's called the NIACAP (NSTISSC 1000), here.
Simply put: It defines a complete, scaleable, tailorable and relevant process to design, test, certify and maintain a system for use.
IF: 1. Good, well informed individuals identify vulnerabilities during system design and testing,
2. The upper management commits to following the maintenance plan, and
3. The priciples of good system design are followed (i.e. KISS, enforcement of least privilege), then many security issues are non-issues.
IMHO, one of the most important things in certifying a system for a critical app is to get the underlying SW from a reputable vendor, one who identifies "Day 0" exploits immediately, preferrably one on the Common Criteria List, and offers a modularized package to limit the amount of unused but potentially vulnerable code in the system. No system is going to be immediately perfect now and for its entire lifespan, but follow a good maintenance plan and you may even be able to make a M$ system secure!
"If you know yourself but not the enemy, for every victory gained you will also suffer a defeat." -Sun Tzu
This isn't any longer the case.
My father is a marine consultant, and I have been to several ships with him, which rely much more heavily than this on computer systems these days.
One specific example-
The charts used to navigate by a ship were running on an NT workstation on the bridge of the vessel. It is no longer a requirement for up to date backup charts to be kept on board. A CD is sent to the ship each week updating the charts to the latest version, but the backup paper charts that are kept are not updated at these regular intervals any longer because of the increased reliance on the NT charting software. The GPS onboard the ship updates the ships current position on the charting software running on the NT workstation so the master can see where they are with respect to the course that has been plotted previously.
This same ship contains a small network, only consisting of 4-5 computers (its only a coastal tanker). One for charting on the bridge, one controlling & monitoring the amount of oil flowing on/off the ship in dock etc.. but..
The ship also has access to email (and consiquently attachments) at sea via Immersat satellite software + (uhh-ohh) Microsoft Outlook. If a member of the ships crew were to open an email attachment apparently from the office, which was in fact a virus, and the network security was not up to scratch, it may have the capacity to shut down not only the ships main course plotting software (sending them to backup paper charts), but to disturb the monitoring of oil/balast on & off the ship in the dock.
There are also proposed inprovements which would in effect link in the course plotting software with the autopilot, thus controlling the ships movements from the PC's course plotting software (unless of course, any evasive action were needed to be taken - the master would switch to manual).
This is only a small example of the problems that could genuinely be caused if a virus infected some of the more modern ships in todays world.