The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 22 Issue 41

Thursday 5 December 2002

Contents

Understanding the Windows 2000 EAL4 Evaluation
Jonathan S. Shapiro
L.A. woman gets prison in counterfeit software ring
Monty Solomon
NSF Fastlane Exposes PINs
Geoff Kuenning
UK Government under digital attack: security breaches revealed
Ian Cuddy
Internet eBay auction scam
NewsScan
Re: eBay sends plaintext password changes
George C. Kaplan
Re: Patch slip-up raises security questions
Fred Cohen
REVIEW: "XML Security", Blake Dournaee
Rob Slade
REVIEW: "A Guide to Business Continuity Planning", James C. Barnes
Rob Slade
CFP: Workshop on Investigation & Reporting of Incidents & Accidents
C. Michael Holloway
Info on RISKS (comp.risks)

Understanding the Windows 2000 EAL4 Evaluation, Jonathan S. Shapiro

<"Peter G. Neumann" <neumann@csl.sri.com>>
Wed, 27 Nov 2002 7:11:48 PST

Understanding the Windows EAL4 Evaluation
Jonathan S. Shapiro, Johns Hopkins University Information Security Institute
  "Jonathan S. Shapiro" <shap@eros-os.org>
  http://eros.cs.jhu.edu/~shap/NT-EAL4.html
    [Via Bruce Schneier's Crypto-Gram (courtesy of Paul Walczak)]

By now, you may have heard that Microsoft has received a Common Criteria
certification for Windows 2000 (with service pack 3) at Evaluation Assurance
Level (EAL) 4. Since a bunch of people know that I work on operating system
security and on security assurance, I've received lots of notes asking "What
does this mean?" On this page I will try to answer the question. For the
impatient the answer is:

Security experts have been saying for years that the security of the Windows
family of products is hopelessly inadequate. Now there is a rigorous
government certification confirming this.

Since that's a pretty strong statement, bear with me while I try to explain
it in plain English.

How a Security Purchase Should Work (In Abstract)
At the risk of telling you something you already know, here is how a
purchaser ought to proceed when buying a security product:

  * Assess your needs. Determine what your requirements are.
  * Decide which product you are most confident will meet those needs.
  * Buy and deploy it.

Each of these is potentially an involved process, and most customers don't
have the expertise to do them effectively. Even if you did, Microsoft (or
any other vendor) isn't likely to let you examine their code and design
documents in order to evaluate their product.

The purpose of the Common Criteria process is to develop standard packages
of commonly found requirements (called Protection Profiles) and have a
standard process of independent evaluation by which an expert evaluation
team arrives at a level of confidence for some particular software product.

As a customer, this makes your life simpler, because you can compare your
needs against existing requirements constructed by experts and then see how
well the software you are buying meets those requirements. Security
requirements are fairly hard to write down correctly, but if the resulting
document is annotated properly they aren't all that hard to understand.

Obviously, if you don't know your needs (requirements) you don't stand much
of a chance of getting them met. Likewise, if you don't know what
requirements a software product was evaluated against, the evaluation result
isn't terribly useful to you in practical terms.

How Common Criteria Works

>From the customer perspective, a Common Criteria evaluation has two parts:

A standardized requirements specification called a Protection Profile that
says what the system is supposed to do. Sometimes there will be more than
one of these -- usually a general baseline protection profile and then some
others describing additional, specialized requirements.

An evaluation rating. This is basically an investigation by well-trained
experts to determine whether the system actually meets the requirements
specified in the protection profile(s). The result of the evaluation is an
"Evaluation Assurance Level" which can be between 1 and 7. This number
expresses the degree of confidence that you can place in the system.

In order to understand the result of an evaluation, you need to know both
the evaluation result, which will be a level between EAL1 and EAL7, and the
protection profile (the requirements that were tested). Given two systems
evaluated against the same protection profile, a higher EAL rating is a
better rating provided the requirements meet your needs.

Knowing that a product has met an EAL4 evaluation -- or even an EAL7
evaluation -- tells you absolutely nothing useful. It means that you can
have some amount of confidence that the product meets an unknown set of
requirements. To give a contrived example, you might need a piece of
software that always paints the screen black. I might build a piece of
software that paints the screen red with very high reliability, and get it
evaluated at EAL4. Obviously my software isn't going to solve your problem.

The Windows 2000 Evaluation
Microsoft sponsored an evaluation of Windows 2000 (with Service Pack 3 and
one patch) against the Controlled Access Protection Profile (plus some
enhancements) and obtained an EAL4 evaluation rating. This is most
accurately written as "CAPP/EAL4".

Problem 1: The Protection Profile

The Controlled Access Protection Profile (CAPP) standard document can be
found at the Common Criteria website. Here is a description of the CAPP
requirements taken from the document itself (from page 9):

The CAPP provides for a level of protection which is appropriate for an
assumed non-hostile and well-managed user community requiring protection
against threats of inadvertent or casual attempts to breach the system
security. The profile is not intended to be applicable to circumstances in
which protection is required against determined attempts by hostile and well
funded attackers to breach system security. The CAPP does not fully address
the threats posed by malicious system development or administrative
personnel.

Translating that into colloquial English:

Don't hook this to the Internet, don't run e-mail, don't install software
unless you can 100% trust the developer, and if anybody who works for you
turns out to be out to get you you are toast.

In fairness to Microsoft, CAPP is the most complete operating system
protection profile that is presently standardized. This may be the best that
Microsoft can do, but it is very important for you as a user to understand
that These requirements are not good enough to make the system secure. It
also needs to be acknowledged that commercial UNIX-based systems like Linux
aren't any better (though they are more resistant to penetration).

Note that the "Don't install software" part means that you probably
shouldn't install a word processor. On several occasions Microsoft has
unintentionally shipped CD's with viruses on them. A CD with a virus
qualified as "malicious system development."

Problem 2: The Evaluation Assurance Level

Having described the requirements problem, I now need to describe the
problem of the EAL4 evaluation assurance level that Windows 2000 received.

As I mentioned before, EAL levels run from 1 to 7. EAL1 basically means that
the vendor showed up for the meeting. EAL7 means that key parts of the
system have been rigorously verified in a mathematical way. EAL4 means that
the design documents were reviewed using non-challenging criteria. This is
sort of like having an accounting audit where the auditor checks that all of
your paperwork is there and your business practice standards are
appropriate, but never actually checks that any of your numbers are correct.
An EAL4 evaluation is not required to examine the software at all.

An EAL4 rating means that you did a lot of paperwork related to the software
process, but says absolutely nothing about the quality of the software
itself. There are no quantifiable measurements made of the software, and
essentially none of the code is inspected. Buying software with an EAL4
rating is kind of like buying a home without a home inspection, only more
risky.

The Bottom Line for Windows 2000

In the case of the CAPP protection profile, there actually isn't much point
to doing anything better than a low-confidence evaluation, because the
requirements set itself is very weak. In effect, you would be saying "My
results are inadequate, but the good news is that I've done a lot of work so
that I can be really sure that the results are inadequate.

In the case of CAPP, an EAL4 evaluation tells you everything you need to
know. It tells you that Microsoft spent millions of dollars producing
documentation that shows that Windows 2000 meets an inadequate set of
requirements, and that you can have reasonably strong confidence that this
is the case.

Conclusion

Security isn't something that a large group can do well. It is something
achieved by small groups of experts. Adding more programmers and more
features makes things worse rather than better. Microsoft has been adding
features demanded by their customers for a very long time.

It is possible to do much better. EROS, a research operating system that we
are working on here in the Systems Research Laboratory at Johns Hopkins
University, should eventually achieve an EAL7 evaluation rating, and is
expected to provide total defense against viruses and malicious code. It
won't be compatible, because the most important security problems in Windows
and UNIX are design problems rather than implementation problems. In fact,
none of the viable research efforts toward secure operating systems are
compatible with existing systems.

It remains to be seen whether EROS or one of the other attempts to build
secure operating systems will prevail, but better solutions are coming.

  [We somehow keep coming back to electronic voting machines in RISKS.  The
  2002 FEC "Voting System Standards" document says that COTS software does
  not have to be inspected if it is used in the construction of a voting
  system.  So any voting machine using Win2K can claim Common Criteria
  compliance, even though it may be riddled with security flaws!  PGN]


L.A. woman gets prison in counterfeit software ring

<Monty Solomon <monty@roscom.com>>
Sat, 23 Nov 2002 19:10:50 -0500

A Los Angeles woman was sentenced on 22 Nov 2002 to nine years in prison and
ordered to pay $11 million in restitution for her role in one of the largest
counterfeit software cases in U.S. history.  The sentence imposed on
52-year-old Lisa Chen by Superior Court Judge Ronni MacLaren was the longest
prison term for a first-time conviction on software piracy, prosecutors
said. ...  [Reuters, 22 Nov 2002]
     - http://finance.lycos.com/home/news/story.asp?story=30082290


NSF Fastlane Exposes PINs

<Geoff Kuenning <geoff@cs.hmc.edu>>
Wed, 4 Dec 2002 12:09:33 -0800 (PST)

Today is the deadline for submitting reference letters for applicants for
NSF graduate fellowships, and the quickest way to do so is through FastLane.
Most of their system is relatively friendly, but when you begin working on a
new student, you are asked for a PIN (actually, it's a password) and the
following message is displayed:

  Your PIN will be used to identify you for future access to
  your Reference Report and to protect it from unauthorized access.

Note that it does *not* give any information about how long the PIN might be
necessary, whether it will be shared among other students you are creating
references for, or what might be a good algorithm for selecting a PIN.
Lacking such, and being in a hurry, I foolishly chose one of my standard
passwords that I use for a number of moderately secure applications.

Imagine my surprise when a few moments later I received a cleartext e-mail
telling me the PIN I had chosen!  Nowhere on the Web page does the NSF hint
that the "secret" value you are typing will immediately be mailed to you in
cleartext.  Since many people manage password explosion by reusing
passwords, this could potentially expose the password to much more critical
things than reference letters.

    Geoff Kuenning   geoff@cs.hmc.edu   http://www.cs.hmc.edu/~geoff/


UK Government under digital attack: security breaches revealed

<"Ian Cuddy" <ic@egovmonitor.com>>
Mon, 2 Dec 2002 19:48:02 -0000

By Ian Cuddy, eGov monitor Weekly
www.egovmonitor.com/newsletter/signup.asp

UK Government departments have experienced more than 9,000 "digital attacks"
on their IT systems so far this year, it has emerged.

The security threat was revealed in Ministers' responses to a series of
parliamentary questions tabled by Labour Party backbencher Brian White MP.

Over half of the incidents were directed towards the Cabinet Office and its
agencies, which during 2002 reported some 5,857 attacks, with 1,167 of these
occurring in October alone. Douglas Alexander, the Minister for
e-Transformation, said that none of the events had resulted in "compromise,
loss or damage to any information held on the systems".

By contrast, the Treasury, the Foreign and Commonwealth Office, Department
for Education and Skills and the Department for Culture, Media and Sport
said they had not detected a single attack on their systems this year. The
Treasury admitted, however, it had discovered in June that an external
website had been attacked while it was still under construction.

The Ministry of Defence confirmed that 10 computer hacking incidents,
including a website defacement, had taken place since January although none
of these, it said, had a "significant" impact on military operations or core
Defence business.

The Home Office reported no hacking attempts this year but said that around
2,500 attacks involving computer viruses had been detected. In the same
period the Department for Environment, Food and Rural Affairs said it had
experienced 564 attacks which were all blocked by its security measures.

The Department for International Development also disclosed a series of
incidents where viruses had infected internal computers. In April the
destructive Elkern virus slipped past the Department's defences and spread
to 500 PCs - about one in six computers - before it was stopped. The DFID is
currently conducting a review of anti-virus arrangements which is expected
to be completed and put into effect by the end of this month.

Ian Cuddy, Chief Editor, eGov monitor  www.egovmonitor.com
T 020 7384 1551  F 020 7384 2551  E ic@egovmonitor.com


Internet eBay auction scam

<"NewsScan" <newsscan@newsscan.com>>
Thu, 05 Dec 2002 09:15:16 -0700

A 27-year-old Los Angeles man, Chris Chong Kim, has been charged with
defrauding eBay buyers on six continents who had purchased computer
equipment from him but never received delivery of the products they had
purchased.  The criminal complaint against Kim details losses of $453,000 to
26 U.S. customers and to eBay and Bank of America.  If convicted, Kim will
face a penalty of up to 24 years in prison.  [Reuters/*USA Today*, 4 Dec 2002;
NewsScan Daily, 5 December 2002]
  http://www.usatoday.com/tech/news/2002-12-04-ebay-scam_x.htm


Re: eBay sends plaintext password changes (B.R.Neumann, RISKS-22.40)

<"George C. Kaplan" <gckaplan@enceladus.Net.Berkeley.EDU>>
Wed, 27 Nov 2002 09:58:58 -0800 (PST)

: An unscrupulous person at an ISP could take advantage of this by sending out
: faked eBay change-password e-mails and sniffing for password changes coming
: through.

There are lots of scenarios that wouldn't even require any help from ISP
insiders.  Anyone could do this at a public wireless hotspot, for example.

George C. Kaplan, Communication & Network Services, University of
  California at Berkeley  1-510-643-0496 gckaplan@ack.berkeley.edu


Re: Patch slip-up raises security questions (Solomon, RISKS-22.40)

<Fred Cohen <fc@all.net>>
Wed, 27 Nov 2002 06:45:11 -0800 (PST)

> [Re: BIND] The delay, coupled with messages sent to several administrators
> urging them to pay to become part of an early-warning group run by the
> ISC, has some security experts worried that security is taking a backseat
> to secrecy and money.  ...

Sounds more like a shakedown to me.  If this story is accurate, the
consortium appears to be threatening other entities with collapse of their
infrastructure unless they pay the consortium for the information on how to
be safe.  This is, in many ways, similar to what the AtStake folks used to
do.  They would create vulnerability exploit scripts and then sell the
defenses to the vendors prior to making the attack script available for
free.

I guess it's time to move away from BIND to a source that is truly open,
and perhaps one that is really secure.  Which brings up point 2.  BIND has
been around for many many years.  It seems to me that the effort put into
patching and reworking this software long ago exceeded the cost of doing a
trusted version.  If it is in the national interest to secure this
infrastructure, when will the government act in the common defense and
provide properly skilled people with the $s to do these jobs right once and
for all?

Fred Cohen  http://all.net/  fc@all.net  fc@unhca.com  tel/fax: 925-454-0171
Fred Cohen & Associates	- University of New Haven - Security Posture


REVIEW: "XML Security", Blake Dournaee

<Rob Slade <rslade@sprint.ca>>
Tue, 3 Dec 2002 07:42:56 -0800

BKXMLSCR.RVW   20021003

"XML Security", Blake Dournaee, 2002, 0-07-219399-9, U$59.99
%A   Blake Dournaee
%C   300 Water Street, Whitby, Ontario   L1N 9B6
%D   2002
%G   0-07-219399-9
%I   McGraw-Hill Ryerson/Osborne
%O   U$59.99 800-565-5758 fax: 905-430-5020
%O  http://www.amazon.com/exec/obidos/ASIN/0072193999/robsladesinterne
%P   379 p.
%T   "XML Security"

Chapter one is an outline of the book.  The differences between
symmetric and asymmetric cryptography are given in chapter two, which
provides a good treatment of the basics, although there are odd
additions of extraneous details.  The XML primer, in chapter three,
follows the all-too-common practice of describing syntax rather than
function, but the explanation of document parts is useful.  The syntax
of XML digital signatures, and a brief mention of canonicalization,
makes up chapter four.  Part two of the introduction to signatures is
in chapter five, which concentrates on canonicalization, but does not
present this important concept clearly.  Chapter six provides some
examples, although neither the problems nor the solutions are defined
well.  The elements of XML encryption are listed in chapter seven.
Chapter eight is a promotion for an RSA product.  The elements of the
XML key management specifications are given in chapter nine.

While the syntax of various XML operations is provided properly, the
book fails to provide the newcomer to the field with any understanding
of the uses or limitations of the XML security provisions.

copyright Robert M. Slade, 2002   BKXMLSCR.RVW   20021003
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade


REVIEW: "A Guide to Business Continuity Planning", James C. Barnes

<Rob Slade <rslade@sprint.ca>>
Tue, 19 Nov 2002 07:47:24 -0800

BKAGTBCP.RVW   20020922

"A Guide to Business Continuity Planning", James C. Barnes, 2001,
0-471-53015-8, U$35.00
%A   James C. Barnes
%C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
%D   2001
%G   0-471-53015-8
%I   John Wiley & Sons, Inc.
%O   U$35.00 416-236-4433 fax: 416-236-4448
%P   174 p.
%T   "A Guide to Business Continuity Planning"

Chapter one is an introduction, and also introduces us to a
characteristic of the book: enormous tables with little apparent
purpose.  Table 1.1 is a list, by country, of regulatory agencies that
may have something to require from you in the way of business
continuity planning (BCP).  The table is stated to be for motivational
use, but does point out some BCP ideas or policies.  There is also a
rather innocent sounding mention that the book is written from the
perspective of a consultant: this fact is more significant than the
reader may realize.  For project foundation, chapter two does not give
the usual advice to get management on-side and build a broadly based
team, but concentrates on costing, expanding, and selling consulting
services.  (There are confusing areas: having presented one
questionnaire, the text tells you to use results from "the two."  Some
items (such as the advice to use a month's worth of invoices to
estimate rate of consumption of supplies) are helpful, but a lot of
space seems to be wasted (on things like pages of fake employee and
customer data--and a month's worth of supply invoices).  The list of
threats, consequences, and preventive measures is more than usually
detailed (and listed twice), in chapter three, but the discussion of
business impact analysis (BIA) itself is *extremely* terse.  Chapter
four's initial material on strategy selection is quite confused.  The
example RFP (Request For Proposal) for business continuity services
does have some good points, but the pages of lists of specific PCs to
be provided seem pointless.  Later details are brief, but reasonable.
Plan development, in chapter five, assumes multiple teams and, again,
has some good points (the provision for leadership succession), but
the lists become too specific in many places (does the top level
emergency management team really all need to do CPR?)  There is almost
no general discussion of testing and maintenance in chapter six.

The book is not necessarily wrong, but only has enough real material
for a good magazine article.

copyright Robert M. Slade, 2002   BKAGTBCP.RVW   20020922
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade


CFP: Workshop on Investigation & Reporting of Incidents & Accidents

<"C. Michael Holloway" <c.m.holloway@larc.nasa.gov>>
Tue, 03 Dec 2002 08:30:06 -0500

The following Workshop should be interesting to many RISKS readers.

C. Michael Holloway, Senior Research Engineer, NASA Langley Research Center
General Chair IRIA 2003  <http://shemesh.larc.nasa.gov/iria03/>
Workshop on Investigation & Reporting of Incidents & Accidents

IRIA 2003 (First Call for Papers)
<http://shemesh.larc.nasa.gov/iria03/>
Mirror at <http://www.logicteacher.com/iria03/>
Deadline: 28 March 2003


The 2nd Workshop on the Investigation and Reporting of Incidents and
Accidents (IRIA03) will be held 16 - 19 September 2002, at the Radisson
Fort Magruder Hotel & Conference Center in Williamsburg, Virginia, United
States.

Incident and accident investigation and reporting systems play a primary
role in the safety of many industries across the globe. These systems are
diverse; the practices and techniques that have been developed within one
industry are seldom shared by those in other areas. Similarly, techniques
that have been developed within one national industry are often different
from those that are used in the same industry in other countries. These
observations have considerable practical consequences. It can be difficult
or impossible to exchange data between these many diverse systems.
Similarly, it can be difficult to ensure that `best practices' are
effectively transferred between industries and between national systems.
This workshop is intended to provide a forum for the exchange of
information about incident and accident investigation and reporting systems
in many different application domains, including but not limited to
aviation, automotive industry, chemical process industry, healthcare,
military systems, marine systems, the rail industry, and nuclear applications.

Topics of interest include, but are not limited to, the following:

o incident and accident causal analysis techniques

o investigatory techniques, particularly for gathering of evidence

o forensic software engineering and techniques for analyzing software failure

o presentation and dissemination of safety-related information and
recommendations

o integrating incident and accident recommendations into broader risk
analysis and assessment

o the integration of human factors, system engineering, and management
concerns

o data mining and trending techniques for incident and accident data

o validation and the monitoring of incident and accident investigation and
reporting systems

o field studies in the application of incident and accident reporting

o studies of the rhetoric of incident and accident reports

o tools for supporting incident and accident investigation and reporting

Authors should submit full papers not exceeding 6000 words to the Program
Committee Chair, Barry Strauch <STRAUCB@ntsb.gov>, by 28 March
2003.  Papers should consist of original work not submitted elsewhere.
Electronic submissions are encouraged.  PDF is the preferred format, but
other formats will be accepted for initial submissions.

Authors will be notified of the Program Committee's decision by 23 May
2003.  Authors of accepted papers will be given instructions about the
required format of the final papers.

Revised final versions of all papers must be received by 14 July 2003 for
inclusion in the Workshop Proceedings, which will be published as a NASA
Conference Publication.  Final papers will also be published on the
workshop web site.

General Chair: C. Michael Holloway, NASA Langley Research Center

Program Committee Chair: Barry Strauch, National Transportation Safety Board

Program Committee Members (with more to be added)
D. Busse, Microsoft
E. Byrne, NTSB
F. Chandler, NASA
J. Davies, U. Calgary
K. Hanks, U. Virginia
M. Holloway, NASA
C. Johnson, U. Glasgow
J. Knight, U. Virginia
P. Ladkin, U. Bielfeld
N. Leveson, M.I.T.
R. Mumaw, Boeing
M. O'Leary, British Airways
T. Panontin, NASA
J. Stoop, Tech. Univ. of Delft
B. Strauch, NTSB
T. van der Schaaf, Eindhoven U. of Tech.

For the latest information about IRIA03, visit the web site at
<http://shemesh.larc.nasa.gov/iria03/>.  If you have any problems with that
address, try the mirror at <http://www.logicteacher.com/iria03/>

C. Michael Holloway, Senior Research Engineer, NASA Langley Research Center
General Chair IRIA 2003  <http://shemesh.larc.nasa.gov/iria03/>
Workshop on Investigation & Reporting of Incidents & Accidents

Please report problems with the web pages to the maintainer

Top