Slashdot Mirror

• Mandatory security and access labelling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sensitivity labels when data is exported).
• Auditing of labelled objects.
• Mandatory access control for all operations.
• Ability to specify security level printed on human-readable output (e.g. printers).
• Ability to specify security level on any machine-readable output.
• Enhanced auditing.
• Enhanced protection of Operating System.
• Improved documentation.
• Example OSes are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS, Harris CS/SX, SGI Trusted IRIX.

• Notification of security level changes affecting interactive users.
• Hierarchical device labels.
• Mandatory access over all objects and devices.
• Trusted path communications between user and system.
• Tracking down of covert storage channels.
• Tighter system operations mode into multilevel independent units.
• Covert channel analysis.
• Improved security testing.
• Formal models of TCB.
• Version, update and patch analysis and auditing.
• Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.

• ACLs additionally based on groups and identifiers.
• Trusted path access and authentication.
• Automatic security analysis.
• TCB models more formal.
• Auditing of security auditing events.
• Trusted recovery after system down and relevant documentation.
• Zero design flaws in TCB, and minimum implementation flaws.
• The only B3-certified OS is Getronics/Wang Federal XTS-300.

• Formal methods and proof of integrity of TCB.
• These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP.

• Mandatory security and access labelling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sensitivity labels when data is exported).
• Auditing of labelled objects.
• Mandatory access control for all operations.
• Ability to specify security level printed on human-readable output (e.g. printers).
• Ability to specify security level on any machine-readable output.
• Enhanced auditing.
• Enhanced protection of Operating System.
• Improved documentation.
• Example OSes are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS, Harris CS/SX, SGI Trusted IRIX.

• Notification of security level changes affecting interactive users.
• Hierarchical device labels.
• Mandatory access over all objects and devices.
• Trusted path communications between user and system.
• Tracking down of covert storage channels.
• Tighter system operations mode into multilevel independent units.
• Covert channel analysis.
• Improved security testing.
• Formal models of TCB.
• Version, update and patch analysis and auditing.
• Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.

• ACLs additionally based on groups and identifiers.
• Trusted path access and authentication.
• Automatic security analysis.
• TCB models more formal.
• Auditing of security auditing events.
• Trusted recovery after system down and relevant documentation.
• Zero design flaws in TCB, and minimum implementation flaws.
• The only B3-certified OS is Getronics/Wang Federal XTS-300.

• Formal methods and proof of integrity of TCB.
• These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP.

Now, before we all laugh and say "doesn't it show that the certifications are stupid?" consider this.. maybe the certification system does work, and all those other certified products are equally flaky. I've got a list of some TCSEC-certified systems here and frankly it's a pretty unappealing set of OSes. If there were as many Unicos systems (rated B1) out there as there were Windows, I betcha they'd find holes in it soon enough. The fundamental problem with any popular OS is that there will be thousands of hackers and wannabees probing away at it. I don't think there are many people reverse engineering CA-ACF2 MVS in their bedrooms.

I think the motto should be: "Security Through Obscurity" - perhaps all those horrid proprietry OSes did have a point after all.

• Boeing's MLS LAN Secure Network Server System
• Boeing's MLS LAN Network Component MDIA, Version 2
• Gemini's Gemini Trusted Network Processor
• Honeywell's SCOMP Version STOP Release 2.1

The BLACKER system also made A1, but wasn't a commercial product. The VMS varient was designed for A1, but I"m not sure if it ever completed evaluation (I don't see it on the EPL).

Yes, a mathematical proof of security was required, at least for the mandatory access control policy (folks typically didn't model DAC).

Daniel

I don't know who wrote this but it's a standard article of faith(sic) in the IT industry.

The only case I can think of in which a vendor provides a meaningful statement that a system operates with a particular fitness for purpose would be systems evaluated under Common Criteria orTSEC

And these systems differ from the vast majority of operating software systems in that:

• Certification is made only wrt a specific hardware configuration
• In the case of A - level MLS systems there has been a formal proof of security
• B - level MLS systems require extensive design and audit validation
• None of the above necessarily guarantee the absence of coding errors / holes

So the current state of the art is "software is too complex to guarantee performance", this is codified in commercial code and practice. What this means for now is that entitities which use software cover themselves with insurance. (I have no idea what it costs to insure a commercial web-presence.)

I think changing things to hold producers of commercial software and systems would be a good step. I can't see however how this would happen without forcing considerable change in the practice of software design and development.

Either tehcnology and QA need to change, or software systems would need to become simple. Given the current set of assumptions it is effectively impossible to perform an analysis of any non-trivial code and determine that it is safe in the expected execution environment(s).

Simplicity sounds great on paper. At present there isn't a market for simple software that works with high assurance. (Look at the tiny marketshare for the BSD's). Even the systems that run over unix-like / oss show a degree of bloat that continues to push reliability out the window.

Prudence and solid engineering practice in operations dictate that we use the simpler / more robust tools in key locations. So BSD or secured versions of linux get deployed as firewalls etc, and critical application and database servers are run with various redundancies (clustering / failover etc), which effectively throws hardware at solving the software 'problem'

Which is just another name for insurance.

The Melissa worm :)

Now thinking about how a proper reference monitor could have been implemented in outlook to completely avoid this worm and all the others, and how these implementations are often just a few hundred lines of code - I vote for the "missing reference monitor" in Outlook to be the most expensive *missing* data out there ;)

(See TCSEC for a description of the reference monitor concept, if you don't know about it)

You're correct about the risk, but the Government has strict standards that systems must adhere to, both when they go into production and when they are in initial development. The Common Criteria site has a listing of protection profiles that basicly spell out all the requirements a system must adhere to in order to be considered 'secure.' In the Labeled Security Protection Profile (and likely the others...I'm only familiar with this one) there is a section that basicly states that "the developer must use a content management system" and provide all documentation for how it functions, is administered, and how changes to the content are tracked.

In other words if any government group were to use an open source product or start one of their own they are still required to keep their copy of the source tree for the code under rigid, monitored control to ensure what happened to irssi and FragRoute could not happen to their project.

I'm not saying that CVS will be the total solution to this problem, but it's nice to see that they do have measures built-in to mitigate the risks.

It's also worth mentioning that the second you attach that NT system to a LAN (or any other network iirc) it is no longer C2 certified.

That is not the case for NT4. The cited report refers to the NT 3.51 evaluation since the NT4 evaluation had not been published when it was written. The summary of the NT4 evaluation says "A networked configuration was evaluated for interconnecting the various hardware with Windows NT workstations and servers.". The full evaluation report is available for those who want to read it.

Windows NT4 (with specified SPs and fixes) also has an ITSEC E3/F-C2 certificate, and networking is mentioned in that one too - search from the CESG certified products page if you want details.

These certificates do not necessarily mean much in practice, but we should refer to up to date ones if we refer to them at all.

If the the EGOVOS announcement goes beyond vapor, CC may be in the future of Linux. For some reason though Slashdot just won't accept that as a story.

BTW, you might want to get a handle on the basic background of CC before shooting your mouth off. TCSEC is no longer accepting new products for evaluation, though those who started the old process can finish it. Common Criteria really means it now. Read the friendly website.

Of course aside from auditing your systems and "finding" problems. You'd also have to make sure the vendor that you pick will provide "solutions" (as many have stated above).

One good benchmark to base their work off is Orange Book certification for your systems. If they (auditor) don't know what this is, I'd stay away from them like the plague. Especially if you're trying to get in good graces with government agencies.

If it's good enough for the Pentagon, I'd guess it'd be a good reference for others. Though for a system to be truly "Orange" I think it needs to be unplugged from the network or something. :)

Software liability, in the same sense as liability for a "standard" engineering product (electrical appliances, cars, buildings, etc.) is, like you say, ludicrous. That's because companies can employ underwriting laboratories to do testing that would exceed the cost of an in-house testing matrix. Engineering is governed by the laws of physics, which generally can tell you a lot about how resistant a building is to heat, wind, rain, etc. In general, software is just plain not tested enough. This is the biggest problem to the formulation of software engineering as a respectable discipline on par with civil or mechanical engineering.

1. Businesses can crumble because of security assured to them by their software vendor that doesn't exist. People lose houses, jobs, and families because of this kind of thing. Security is dependent on more than just each component of a solution being appropriately secure - it needs the combination of each individual piece to be secure. This task is, in general, too difficult for the average tech lead at a small business, college, or school, who will have enough problems with basic functionality. To some extent, the burden needs to be shifted to software providers- I don't think this is a point of contention.

2. It is easy to purchase the software you need, with a guarantee of security and reliability, and at a reasonable price, only if you are involved with the government of a large country, and even then you don't always get it right.

3. IIS on its own may be secure enough for a company intranet, but if the intranet's firewall and proxy servers are compromised, then it has become not secure enough. Schneier wants insurance companies to take the brunt of deciding how effective security solutions are - not the US government.

4. Schneier's main goal in instituting software liability is the management of security risk by lowering insurance premiums for people with more secure software. People who want to develop software without liability protection can count on an according security check level - if a system was in place that made security important for everybody, and not just these guys, the world might be a better place.

5. There are enough larger players within the software world that I don't think this would happen - specifically, IBM wants to protect AIX, Apple wants to protect OS X, and Sun wants to protect Solaris. And if IBM and the NSA want to continue to promote Linux, they WILL make it secure

6. OpenBSD has had four years without a remote hole in the default install configuration - it has also had several local holes, and this is entirely discounting the problem of people who configure the software the wrong way. People are choosing to do this, and the market is sorting it out, but not to the extent that's necessary to prevent another Nimda, Code Red, or Iloveyou virus - the cost in lost productivity alone is earth-shattering. And people don't need to get hacked for terrible things to happen to them- in fact, if they never figure it out, all the better for the attacker. No, for the most part, people don't care- and they should. Most people don't want to get vaccinated, but we make them- because the cost to not get vaccinated for society as a whole is that much greater.

Granted, the US government runs mainly under Windows systems

As hinted at in another post here, there's a difference between what's certified and what individual practioners would see as accurate. The reason is the individual practioner sees systems applied in real world scenarios and these don't necessarily have anything to do with certification standards. For instance, Cold Fusion and IIS problems are simply not a factor in evaluating the OS even though in the case of IIS it's arguable as to whether this should be.

Additionally, you need to understand just what is being evaluated at the different levels. As mentioned, WinNT was given C2 certification. Understand that this has everything to do with a particular feature set (fine grained ACLs primarily) and little to the with the penetrability of the system. Actual pen testing doesn't become a requirement until B1, IIRC.

The type of security that many are trying to achieve now (secure design, design verification, secure distribution, etc. i.e. security from the start) really doesn't come into play until A1 and that's the highest level of security deemed practicle in the TCSEC.

If you read the Orange book all the way through, what you'll see is that the majority of the security is intended to be achieved via mandatory access controls, subject and object labeling, and the careful application of these concepts. Each level has a new set of requirements for how much of the system is submitted to manadatory access control, whether the TCB (trusted computing base) is a subsystem of a greater insecure system, modularity and seperation of duties, etc. Much higher level system design issues and features, really. Until B2, B3, and really A1 IMHO there's only basic and passing concern with what we're coming to realize as the one true requirement of security engineering: security from the start. Secure design, verification, implementation, and review.

I haven't closely studied the Common Criteria and the handful of protection profiles yet, but I suspect you'd find the same or a similar issue. These are evaluation criteria and they tend to be focused on evaluating a stated set of features and capabilities. In high security environments product certification is not a replacement for careful product evaluation by the end user/customer any more than skills certification (e.g. Cisco, MS certs) is a replacement for careful interviewing and skills assessment by a hiring manager.

see nt 3.5 and nt 4.0

Curiously the 3.5 eval was just weeks after I reported NT's vulnerable management of passwords over network links to CERT. CERT's reply was "well not enough people are using NT on the internet for this to be an issue.

I also forwarded my data to the TSEC evaluators. They indicated that since the evaluated version of the OS(sic) had had all networking capabilities removed (orange-book doen't cover network security), that the evaluation would not be affected by this hole.

As it happened the vulnerability I'd found was further tied to the internal storage of passwords in the NT Reigisty, later examined in L0ptCrack.

Anyhow enough people want to use NT in secure environments that MS will continue to seek these certifications.

see nt 3.5 and nt 4.0

Curiously the 3.5 eval was just weeks after I reported NT's vulnerable management of passwords over network links to CERT. CERT's reply was "well not enough people are using NT on the internet for this to be an issue.

I also forwarded my data to the TSEC evaluators. They indicated that since the evaluated version of the OS(sic) had had all networking capabilities removed (orange-book doen't cover network security), that the evaluation would not be affected by this hole.

As it happened the vulnerability I'd found was further tied to the internal storage of passwords in the NT Reigisty, later examined in L0ptCrack.

Anyhow enough people want to use NT in secure environments that MS will continue to seek these certifications.

*NITSCAP
*DITSCAP
*Common Criteria
*FIPS 102 Not to mention all the other FIPS criteria, esp. regarding crypto and PKI.
*NIAP (Information Systems Certification Procedures and Assessment Scheme)
*A Plethora Of Schema and Policy
*Ye Olde Rainbow Series
*MIT GASSP [warning, .doc file]

And these are just US criteria...other nations have their own. These are becomming very important, if typical job requirements on security-jobs list are any indication. Need a BS, a clearance, and 5 years practical experiance in everything from LAN wiring, vulerability finding and exploit production, penetration testing, firewalls and IDS, to the evaluation and application of these federal criteria, and everything in between. And that will get you an entry level position!

The Common Criteria:
here and here.

Which supersedes the Orange Book:
here and here.

In a normal hetrogenous environment (as 99% of n/ws are), you're going to be dealing with software and hardware from many different vendors.

It is possible (if not probably) that the interaction of these components will create security holes for an attacker to exploit. Which vendor do you blame? They may all be working as designed. Do you blame your low-paid network guys? Do you spend hundreds of thousands to hire external consultants? Can you blame (and sue) them if your network is breached?

What about default configurations of software? What if the default configuration is insecure, but the documentation describes how to secure it?

I have my own thoughts on these issues, I'd like to see what the general consensus is here.

Btw, if you're looking for a secure OS, try XTS 300 STOP.

The EPL makes interesting reading.

In a normal hetrogenous environment (as 99% of n/ws are), you're going to be dealing with software and hardware from many different vendors.

It is possible (if not probably) that the interaction of these components will create security holes for an attacker to exploit. Which vendor do you blame? They may all be working as designed. Do you blame your low-paid network guys? Do you spend hundreds of thousands to hire external consultants? Can you blame (and sue) them if your network is breached?

What about default configurations of software? What if the default configuration is insecure, but the documentation describes how to secure it?

I have my own thoughts on these issues, I'd like to see what the general consensus is here.

Btw, if you're looking for a secure OS, try XTS 300 STOP.

The EPL makes interesting reading.

FIPS 140-1 is Federal Information Processing Standard 140-1. It's a document describing how the U.S. Government requires itself to do things. Read it here You can be certified compliant, but the process is done by independent labs, not NIST (home of FIPS).

TCSEC is also not a company. TCSEC, or Trusted Computer System Evaluation Criteria, is a book. "The Orange Book", to be specific. It can be found here as well.

The orignal poster's point is well taken, though. Whichever companies provided the certification might consider examining their process.

No OS has recieved an A1 rating. Multics MR11.0 was rated at B2, an honor it shares with Trusted XENIX. Wang currently has several systems at B3, which, AFAICT, are the most secure general-purpose OSes yet evalutated. The only A1 rated products of any sort are a couple network devices and something else from Wang.

No OS has recieved an A1 rating. Multics MR11.0 was rated at B2, an honor it shares with Trusted XENIX. Wang currently has several systems at B3, which, AFAICT, are the most secure general-purpose OSes yet evalutated. The only A1 rated products of any sort are a couple network devices and something else from Wang.

The second article mentions the Department of Defense guidelines for passwords. They're an interesting read.

The sole purpose of the NSA is to spy on you, now why are they trying to make your system more secure?

Incorrect. Read the NSA's charter.

Pay attention to section 1, Article 5, Section 3 et. al. The NSA also is charged with creating standards for the security of information held in DoD computers (specifically), other govt. computers (generally), and promulgating those standards for use in other systems. Here is a nice link to the NSA's computer security guidelines if you haven't seen them.

Yes, the NSA spies on people. No this isn't nice. Yes, the government of the USA does some awfully screwy things, like the DMCA. Tarring the whole government with the same brush is simple-minded.

Besides, the code is available for your perusal. If you think the uberspooks have put in a back door, get to work and find it!

See the entry in the Evaluated Products List for the C2 status of NT4 with SP6a and a C2 update. NT4 with SP3 has an E3/F-C2 evaluation from UK ITSEC.

If you don't already know about these sites, you probably don't want to bother reading the evaluation reports.

If things are so bad for NSA officials to keep tabs on terrorists and the way they commit digital crimes in association with their acts, then why would they release an OS that could further help these terrorists hide/secure their data.

Mandatory Access Control (MAC) is one of the requirements of a B1-secure ("Labeled Security Protection") system under the Trusted Computer System Evaluation Criteria book originally published by NCSC way back in 1983 (the so-called Orange Book). None of the TCSEC security ratings (C2, B1, B2, etc.) mention cryptography. I've seen B1 and even B2 systems (rare though they may be), none of which had encrypted filesystems. Sure, most systems have an encryption capability, but so did Bell Labs Unix - the crypt command. Crypto ain't MAC, and TCSEC don't care 'bout no crypto. The two are orthoganal.

TCSEC is all about isolation and protection - about ensuring that access to data and information is restricted according to clearly defined rules and that information cannot be "leaked" from one security zone to another. What the NSA has produced in Linux SE is a variant of Linux that is harder to crack, even from the inside. Cryptography has nothing to do with that. But that doesn't make Linux SE bad - I'd love a less-crackable Linux, even though I personally despise living under MAC restrictions.

Maybe someone should just tell them about OpenBSD, save some time and money.

The DARPA program is called Composable High Assurance Trusted Systems (CHATS) which implies that they are interested in Trusted Systems not systems that claim to be secure because a bunch of hackers allegedly have fixed all the buffer overflows. Being "secure" and being a trusted system are completely different things.

Maybe micheal meant to mention TrustedBSD which is attempting to become certified as a Trusted System?

The common criteria are far more than the old orange book controls (B1, B2, C1, ...). Part two of ISO 15408 has many things that I'd really like to see (and I'm prepared to help, too).

Why even bother with the old style Orange book stuff, which barely work in a networked environment, when the new style CC definitions are available for free?

Also will you be providing a framework such that deployed TrustedBSD systems are ready for CC evaluation?

Lastly, any plans for a NetBSD version? Want some help?

The government doesn't use Windows, Linux or xBSD for its truly sensitive documents. Instead, the DoD uses Wang's XTS-300, which is tested more extensively than the OpenBSD project and is the highest security rated operating system in existence, as seen here. One thing I thought was cool about this system is that you can't tell with 100% certainty disk space because users could in theory devise a scheme where they could pass messages encoded in changes in availability. For the same reason, if you time a process, some margin is added to the value you would get, which makes message passing take extremely long. The full specs of the Common Critera, an updated "Orangebook" are here.

The government doesn't use Windows, Linux or xBSD for its truly sensitive documents. Instead, the DoD uses Wang's XTS-300, which is tested more extensively than the OpenBSD project and is the highest security rated operating system in existence, as seen here. One thing I thought was cool about this system is that you can't tell with 100% certainty disk space because users could in theory devise a scheme where they could pass messages encoded in changes in availability. For the same reason, if you time a process, some margin is added to the value you would get, which makes message passing take extremely long. The full specs of the Common Critera, an updated "Orangebook" are here.

Many commercial OSes have some kind of evaluation of some version, and some have TCSEC (Orange Book) class B or above (or equivalent under other schemes). If you are really interested, here are some links:

• Trusted Product Evaluation Program for TCSEC evaluations.
• The UK ITSEC scheme has a certified products list - E3/F-B1 is similar to TCSEC B1.
• National Information Assurance Partnership has a list of products validated against the Common Criteria (joint sucessor to TCSEC and ITSEC)

The field has its own specialist jargon, so it may take some effort to make sense of all that. Also remember that resistance to penetration is not required until you get a long way up the scale although it is probably what most people expect to get, only to be disappointed. It is actually very hard to show that a system is penetration resistant, much harder than merely making it penetration resistant (which is hard enough in itself if you want to keep some functionality).

So where do they get their trusted systems from? Either the commercial guys listed here, or from an OS written internally at say, NSA. The hordes of math geniuses they have probably come in real handy for writing trusted systems.

Of course boxes are need to be evaluated, I can have an A1 secure OS, but if the prom allows me to bypass it, then the box isn't secure.

Odd, but I don't see Solaris 7 with PitBull listed as B1. Check http://www.radium.ncsc.mi l/t pep/epl/epl-by-class.html#B1 for yourself. Looks like pure marketing weaseldom.

• Windows NT just barely makes the lowest evaluation level. And that's after years of trying. Plus you need service pack 6A with a fix beyond that; out of the box, NT flunks. Some UNIX variants have done much better. See the Evaluated Products List.
• Anything below a B level isn't secure. B-level systems have mandatory security, which means users can't do insecure things even if they want to. Systems with mandatory security are a pain to use, but the security is real.
• Security policy is a mess UNIX doesn't have a security policy, just lots of permission bits. Systems with mandatory security have a security policy, but it's very restrictive. There have been some efforts to bolt mandatory security onto Linux, but all the administration tools need to be modified to live within the tighter rules (no more root, for example), so not much has happened in that direction.
• What's needed is a liveable security policy that's really secure if enforced, a set of tools that can live within it, and a small microkernel that enforces the rules. Think about issues like how package install can work if it isn't trusted.

While we're naming others, DEC's OpenVMS Vax was also certified C2 (as well as many others). SGI's Trusted Irix was rated B1.

--

You can find all of the rainbow books here and here. They're worth a look.

--

NSA's computer security evaluation program hasn't been very popular. NSA also evaluates security equipment like padlocks and safes, and back in the '80s when they started evaluating computer systems, they thought much the same approach would work. Early on, evaluations were conducted by in-house NSA staff, under a "two-try" system; the system was evaluated once, and if it didn't pass but looked promising, the vendor was given hints on what to fix. The second try was pass/fail; no further tries were allowed. It wasn't considered the job of the evaluation team to debug the system.

The current scheme is much more vendor-friendly. Evaluation is usually done by outside contractors paid by the vendor. The vendor can keep trying to pass as long as they pay the vendor. NSA then reviews the evaluation. That's how NT 4 got through.

Even under the same criteria, the new approach is much easier to pass. Under the old scheme, vendors didn't go for evaluation until they were really confident of their ability to pass, since outright rejection was possible. Now, vendors can submit whatever they've got and keep debugging until they wear down the evaluation contractor. That's not good. Note that it took Microsoft years of trying to get NT 4 through.

C2 is a very low standard. Nothing below B2 is really serious. It's embarassing that NT can't make C2 out of the box.

The list is depressing. Little has been added in recent years. The security properties of commercial products are so weak today that it's embarassing. Yes, the criteria are dated, but that's not the big problem.

I understand that the 3.5 certification was without a network or floppy drive, but that isn't the only C2 rated NT product, which is what I was driving at.

I hate being put into a position where I feel like I'm defending Microsoft, but it's silly to play word games with these ratings. NT 4 has been evaluated at C2, and so it has a C2 rating.

This bores me now. Anyone that actually cares to know can jump around the TPEP site and draw their own conclusions.

At work, we have several NSA certified tape degaussers. The degaussers are certified for media up to 750 oersted at better than -90 dB erasure. They are strong enough to erase the credit cards in your wallet if you stand too close to one that is in operation. Signs are posted that warn people with heart pacemakers to stay out of the area. As strong as they are, they are not powerful enough to securely erase the high coercivity media used in many modern tape cartridges and disk drives. The other problem is that a hard disk enclosure is going to shield the platters inside the drive.

See A Guide to Understanding Data Remanence in Automated Information Systems for the National Computer Security Center guide to the subject.

Secure systems don't have "root."

• Security cannot be achieved by debugging.
  Read the decade of CERT advisories for Sendmail and BIND to convince yourself of this.
• Linux, and UNIX, contain some terrible basic security-related design decisions.
  The notion of "root" is bad enough, but "set-UID to root" is worse. This results in far too much code being trusted. In particular, it should be impossible to run non-trusted code as root. This means no root log-ins, for example. In a secure system, as your privileges go up, the amount of software you're allowed to run goes down. In a sandbox, you can run anything. As administrator, you can only run a few tools that do very specific things with lots of checking. This is completely alien to UNIX.
• Fixing known holes only protects against the inept.
  A serious attacker will find their own holes, and will keep quiet about them until they break in and steal something. Fixing known holes protects against script kiddies.
• If you don't have a security model you can write down on a small piece of paper, you can't enforce it.
  DoD has a simple security model, which is reasonably enforceable. See the Orange Book. There's Linux support for it. You take a performance hit and can't run some popular software. But in that direction lies real security.
• Discretionary security doesn't work.
  With discretionary security, users can turn off security. "chmod 777" is the usual way. With mandatory security, if you're processing SECRET information, nothing you or your programs can do makes it non-SECRET. The problem with discretionary security is that it's extremely difficult to tell if the system is in a secure state, and it's very easy to make a change that opens a security hole.
• Secure systems are no fun
  OK, you've got a secure system. Want to run Napster? No way; it's acting as a server and transmits your files. Want to download a game? If it will run in a sandbox, OK, but it can't talk to other players. Running a web browser may be OK, but the browser will be shot down if it tries to launch MS Word to read a .doc file. And the browser will need some work to live within the restrictions of a secure system.

A secure open-source system is quite possible. But it won't be Linux as we know it.

"Trusted Software" or trusted systems in general are supposed to meet a spcification that was written by the DoD in 1983 (which was an update to docs written in the early 1970's) that outlines appropriate guidelines for access to remote systems and embedded software.

That's almost correct: at this point, you're referring to Orange Book, or DOD 5200.28-STD. It was last updated (as far as I know) in 1985. Otherwise, I agree.

However, remote access to systems is a job not only for the operating system of the host, but also for the network it runs on. Being that networks in 1983 were a little different than they are now, I would hope that a system that was meant to provide access to possibly classified data would rely on more than simply the security of the selected operating system, regardless of the openness of the sourcecode.

Orange Book is specifically about computer systems, not networks, or indeed networked computer systems. If you're interested in what the NSA/DoD has to say about networked systems, then you should probably be looking at the Red Book; aka NCSC-TG-005, which is available somewhere on the NCSC's public webserver: Radium. This server is a tremendous resource to those interested in trusted computer systems; the nice people at Fort Meade will even send you a CD containing the full website, free of charge, if you ask them nicely.

Cheers, Nick.

Sorry for the double post, found the other site with the magic books.
Trusted Network Interpretation Environments Guideline - Guidance for Applying the TNI, 1 August 1990. (Red Book)
DoD Password Management Guideline, 12 April 1985. (Green Book)

That's Orange, Red, Green. Enjoy all.

Malk-a-mite

Identified channels include:

• Space exhaustion
• Unmounting of busy system channels
• Contention for devices like printers
• Timing of processes

CAPP and LSPP are where it's at! CAPP = Controlled Access Protection Profile LSPP = Labelled Security Protection Profile Both of those are defined under the "Common Criteria". Those 2 protection profiles supercede C2 and B1 (and are supposed to be equivalent). To see the 1999 version of DoD requirements, check out http://www.rad ium.ncsc.mil/tpep/library/protection_profiles/inde x.html

Often, vendors refer to this as having "B1 functionality

Before I go on, note that references to B1 are becoming outdated. The TCSEC is being superseded by the Common Criteria (see commoncriteria.org for details). In this criteria, there are protection profiles (generic statements of requirements), that are crafted into Security Targets for specific Targets of Evaluation. The TCSEC B1 rating is being replaced by the Labeled Security Protection Profile (see http://www.r adium.ncsc.mil/tpep/library/protection_profiles/in dex.html). However, as with the TCSEC, a rating involves not only an evaluation of function, but an evaluation of assurance. This assurance includes design documentation, user documentation, installation instructions, and testing. These factors make it difficult to evaluate a generic Linux installation. The features could also complicate matters. For example, if FPT_SEP (in B1 parlance, System Architecture) is included, there is a requirement that the domain for the policy-enforcing portion of the OS must be protected. This is typically done by using kernel mode, and putting users in user mode. This is typically done on a specific hardware platform, so the platform must be known in order to perform the evaluation.

As for A1, I don't think any modern operating system can reach that level. The proof requirements for A1 certification would be prohibitively expensive for anything but the most scaled down system.

There are few A1 systems, but some do exist. Usually, they are not full OSs, but narrower products such as network guards. You are correct in that they are prohibitively expensive to develop.

Ian Bicking wrote:

I get the impression they can't, because the certification includes the installation.

My understanding is they could produce standalone certified system, and offer a service where they install and have certified a network sytem. It would be expensive though. I could be very wrong, since I've never been involved in such a process.

What I wonder is, what operating systems do B1-ready systems run at the present?

That's easy one to answer. According to the TPEP Evaluated Products List, the following operating systems have been used in B1-rated systems:

Amdahl UTS/MTS v2.1.5+
Computer Associates CA-ACF2 MVS v6.1 with CA-ACF2 MAC
Digital SEVMS, several versions on VAX and version 6.1 on Alpha
Digital Ultrix MLS v2.1 on VAXStation (Microvax)
Harris CX/SX v6.1.1 and v6.2.1
HP HP-UX BLS v8.04 and v9.0.9+
SGI Trusted Irix v4.0.5EPL (where this code came from)
Unisys OS1100SR1 and OS1100/2200, Several releases

You'll see that rather than making their mainstream operating system ratable, most vendors (eg. Digital, HP and SGI) offer a special version of the OS that is set up to meet the rating criterion.

----

18. What are the requirements for a D/C1/C2/B1/B2/B3/A1 system?

The Interpreted Trusted Computer System Evaluation Criteria (ITCSEC) available in postscript at contains the definitive set of requirements for each TCSEC class. In Summary:

Class D: Minimal Protection

Class D is reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class.

Class C1: Discretionary Security Protection

The Trusted Computing Base (TCB) of a class C1 system nominally satisfies the discretionary security requirements by providing separation of users and data. It incorporates some form of credible controls capable of enforcing access limitations on an individual basis, i.e., ostensibly suitable for allowing users to be able to protect project or private information and to keep other users from accidentally reading or destroying their data. The class C1 environment is expected to be one of cooperating users processing data at the same level of sensitivity.

Class C2: Controlled Access Protection

Systems in this class enforce a more finely grained discretionary access control than C1 systems, making users individually accountable for their actions through login procedures, auditing of security-relevant events, and resource isolation.

Class B1: Labeled Security Protection

Class B1 systems require all the features required for class C2. In addition, an informal statement of the security policy model, data labeling (e.g., secret or proprietary), and mandatory access control over named subjects and objects must be present. The capability must exist for accurately labeling exported information.

Class B2: Structured Protection

In class B2 systems, the TCB is based on a clearly defined and documented formal security policy model that requires the discretionary and mandatory access control enforcement found in class B1 systems be extended to all subjects and objects in the automated data processing system. In addition, covert channels are addressed. The TCB must be carefully structured into protection-critical and non- protection-critical elements. The TCB interface is well-defined and the TCB design and implementation enable it to be subjected to more thorough testing and more complete review. Authentication mechanisms are strengthened, trusted facility management is provided in the form of support for system administrator and operator functions, and stringent configuration management controls are imposed. The system is relatively resistant to penetration.

Class B3: Security Domains

The class B3 TCB must satisfy the reference monitor requirements that it mediate all accesses of subjects to objects, be tamperproof, and be small enough to be subjected to analysis and tests. To this end, the TCB is structured to exclude code not essential to security policy enforcement, with significant system engineering during TCB design and implementation directed toward minimizing its complexity. A security administrator is supported, audit mechanisms are expanded to signal security-relevant events, and system recovery procedures are required. The system is highly resistant to penetration.

Class A1: Verified Design

Systems in class A1 are functionally equivalent to those in class B3 in that no additional architectural features or policy requirements are added. The distinguishing feature of systems in this class is the analysis derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented. This assurance is developmental in nature, starting with a formal model of the security policy and a formal top-level specification (FTLS) of the design. An FTLS is a top level specification of the system written in a formal mathematical language to allow theorems (showing the coorespondence of the system specification to its formal requirements) to be hypothesized and formally proven. In keeping with the extensive design and development analysis of the TCB required of systems in class A1, more stringent configuration management is required and procedures are established for securely distributing the system to sites. A system security administrator is supported.

--

Fair warning, it's ~250K and definitely not light reading.

© 2000 James Lanfear. All rights reserved.