Windows 2000 declared secure

[Arnold G. Reinhold]

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" <shap at eros-os.org> 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.
>
>> Also 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.
>
>Having read a number of existing protection profiles, I have to say that
>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 
>majordomo at wasabisystems.com


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com