At 6:38 AM -0500 11/4/02, Jonathan S. Shapiro wrote:
Requirements, on the other hand, is a tough problem. David Chizmadia and I started pulling together a draft higher-assurance OS protection profile for a class we taught at Hopkins. It was drafted in tremendous haste, and we focused selectively on the portions of CC we would cover in class, but it may provide some sense of how hard this is to actually do:http://www.eros-os.org/assurance/PP/ASP-OS.pdf
A couple of comments:
I realize that this is a very preliminary draft. Please don't take this as criticism of your protection profile. It is a very useful start. I am not familiar with this stuff, so please accept these comments as coming from a naif.
I think these profiles should start with criteria (functionality, requirements, assumptions, etc.) that directly address non-technical users. Ideally they should be quotable in a white paper describing the benefits of the target of evaluation or, even better, in the product warrantee. More technical criteria added later in the document should be tied to these or explicitly justified in some other manner. The NSA CAPP does this to some extent in sections 3 and 4.
So, for example, requirements on IPL and power fail behavior might derive from a general specifications that the system not be subject to compromise during abnormal situations. A list of such conditions would include IPL and power failures, along with hardware malfunction, periodic maintenance, terrorist attack and so forth. Conditions where security is not protected, say hardware maintenance, would then be made explicit.
I also think there is an opportunity to componentize protection profiles. The designer of a new profile should not have to reinvent stuff like authentication or entropy generation. Profiles for these components would be included by reference, perhaps with parameters for components with options. This has the additional advantage of allowing the components to be updated independently. (Any particular certification would specify the revision level of all components used.) Here are some candidate components, not all of which involve software but are none the less important in secure systems:
o Entropy generation -- there is lots of art that can be captured here, e.g. batching entropy input, that might not be obvious to profile writers
o Login authentication -- again there are many approaches that should be captured, multi-sue password, PKI credentials, multi-factor, no lone access.
o Cryptographic algorithms with key and salt length recommendations-- The widely accepted algorithms and modes of operation might simply be listed, with provision for "Type 1" supplied by some government owner. Home grown algorithms should be banned. By the way your Quantum assumption is too narrow. None of the popular cryptographic algorithms have been mathematically proven secure. This risk should be explicitly stated.
o Secure networking--safe use of TCP/IP stacks, VPNs, services to be avoided, ...
o Multi-site systems --Security solutions employing several machines at individual locations, each backing up the other's data and cross checking proper operation.
o Event logging (e.g. what to log, being careful not to log passwords typed in the wrong box, sending logs to remote sites, dealing with lack of space)
o Configuration management -- validating that the software in use is the software that was certified; secure patch distribution and installation; verification that all patches are installed
o Forensic requirements -- what kind of evidence of misuse must be collected and how must it be handled to have legal standing in various jurisdictions.
o Data port protection -- preventing attacker from breaching security by gaining access to built in ports (RS232, USB, Firewire, SCSI, etc.) This could involve special drives or physical covers.
o Attack detection
o A common threat vocabulary--levels of attacker sophistication (nosy user, malicious insider, script kiddies, teams of hackers, well funded organizations, large national security services) and attack geography (intercepted packets enroute, attacks via publicly accessible ports, war dialing/driving, inside job, physical capture and exploitation of the hardware.
o Detected attack response (this can vary of course. A secure system might zeroize all keys and seeds. A long term archive might publish keys before all data is lost.)
o Secure sensor modules -- GPS receivers, cameras (still and movie), intrusion detectors, sound recorders, biometrics, etc that include a tamper resistant capability to sign the data they produce.
o Power availability assurance (loss of power is a denial of service as much as any flooding attack)
o Physical security, FIPS 140, for example. There may be useful stuff in the DOD Industrial Security Manual and insurance industry guidelines. There are potential tie-ins to software. A system might want to know whether an individual is still in the building before granting access through an inside terminal
o Training requirements and awareness maintenance for users, operators and administrators, including frequency and specific topics to be covered
o Legal forms -- security notices, employee agreements, acceptable use policies, etc.
I can envision this stuff evolving into something like the fire protection regulations that every architect has to either follow or request a waver.
Arnold Reinhold
At 6:38 AM -0500 11/4/02, Jonathan S. Shapiro wrote:
I'm answering this publicly, because there is a surprise in the answer. On Sun, 2002-11-03 at 13:12, Arnold G. Reinhold wrote:"Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: >... If a >reputable group of recognized computer scientists were to publish a well >thought out set of evaluation criteria... If I may ask a naive question, couldn't such a set of evaluation criteria be abstracted from the design goals of Eros?Funny you should ask that. First, I need to correct my original statement: one needs both evaluation criteria and an effective requirement set for a secure OS. The Common Criteria evaluation process needs to be augmented with quantitative tests on the actual software artifact, but it's actually pretty good. Requirements, on the other hand, is a tough problem. David Chizmadia and I started pulling together a draft higher-assurance OS protection profile for a class we taught at Hopkins. It was drafted in tremendous haste, and we focused selectively on the portions of CC we would cover in class, but it may provide some sense of how hard this is to actually do: http://www.eros-os.org/assurance/PP/ASP-OS.pdf Sorry about the formatting errors - it's an automatically generated document that needs cleanup. The difficulty in drafting a PP like this is avoid specifying solutions. A PP is supposed to be a requirements document. Unfortunately, you get into quandries. Some of the requirements we think are important can be done in capability systems but not in non-capability systems (at least based on published verifications to date). It becomes tempting at that point to introduce requirements that can *only* be done by capability systems. Also, much is present only by reading between the lines. An annotated document is needed in order to really make any headway on understanding what is implied by some of the requirements.Having read a number of existing protection profiles, I have to say thatAlso there is no reason such a document need be as voluminous as existing criteria. It is high time we departed from the quality industries practice of focusing on tangential issues, ignoring substance and generating mountains of paper as a proxy for accomplishment.
people have done quite well on this. There *is* some unneeded bulk, but
this is primarily due to conventions that yield consistently styled
documents. Once you understand how to read one PP you can read pretty
much any PP. A modest amount of size expansion is a reasonable price to
pay.
shap
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
