RE: [IDS] IDS Common Criteria

["Graham, Robert (ISS Atlanta)" <rgraham () iss net>]

Common Criteria is for those who believe that "security is a process".

Security is not a process. There is no silver bullet that will protect
you. The Common Criteria process is not a silver bullet.

For example, the NSA has done a Common Criteria certification of
JavaScript. I know this because one of the websites I needed to access
in order to do the certification for ISS uses JavaScript for frivolous
mouse-over GIFs (the menu items change color when you move the mouse
over them). If you don't have JavaScript enabled on the browser, you
can't access the site. I sent e-mail asking about this paradox, and they
replied with all the Common Criteria certification information from the
NSA proving that JavaScript was safe. I'm sure this is a consolation for
all those users infected by Nimda through their browsers, and means I no
longer have to worry about updating Internet Explorer every month.


A common misconception is that the Common Criteria certifies how well an
IDS does it's job. This is wrong, that is not the intent.

The Common Criteria certifies only the "security function". Your product
has its own functionality, even security products like firewalls and
IDS. The Common Criteria doesn't care what your product does, it only
cares whether you do it securely. It doesn't care if hackers can get
through a firewall, it cares only if hackers can break into the firewall
itself. Like all products, an IDS system still has to deal with the fact
that people must log onto the system (to see IDS events, reconfigure
sensors), and the communications among components must be encrypted
(e.g. getting events from the sensors to the database). Common Criteria
asks only if the IDS meets the criteria that are common among all
products that require users to log into them.

The Common Criteria does not insist that you meet ALL the criteria, only
that you list which of the criteria your "security function" meets. Do
users log in? Do you cloak the password with *** as they type it in? Can
you log the date/time when they log in? Can you lock them out during
certain times of the day? Can you audit their actions? Can you encrypt
data between your subsystems? These are all reasonable questions to ask
of a product, and they simply want you to list your answers. EAL1, the
lowest level, is just your list. EAL2 is where you hire
government-trusted consultants to verify that your EAL1 document is
correct by looking at the product and verifying each item. EAL3 is where
they start looking into your design. Higher levels go deeper and deeper
into your design, I think at EAL4 they look at source-code. To get the
nosebleed certifications, you have to design your product from scratch
to meet these requirements: even source-code is not enough to prove
things work, they want to make sure you designed it from scratch to meet
those requirements.

You don't need to do all the criteria (indeed, you can't). You can say
"We DON'T encrypt IDS events from the sensors to the database". This is
where "Protection Profiles" come into play that list, for each customer,
what minimal criteria they want you to meet. They simply match their
profile against you list and see if they match. The Department of Energy
might create an "IDS Profile" that says that in order for an IDS product
to be sold to the department, then it must encrypt IDS events, and that
it was evaluated at level EAL3 for that feature to make sure it works
correctly.


The actual criteria are actually pretty good. These things have been
refined over decades. If you design a product, you should be aware of
the criteria. The problem is, as Randy Taylor describes it, is that the
"process" is bureaucratic at best and Byzantine at worst. I created an
IDS that advanced the state of the art, but that was less effort than
needed to get my hypothetical EAL4 certification for features that match
a typical Protection Profile. I don't deny that certified products are
more secure, I ask only whether the cost to secure them is worth the
sacrifice. Should IDS/firewall engineers spend their time advancing the
state-of-the-art in IDS/firewall technology, or should they stop
innovating in order to deal with the Common Criteria process? Which
makes the Internet more secure? (This is really important because
nothing in the Common Criteria really stops hackers (because,
presumably, they don't bother logging on), but firewalls and IDS do).

-----Original Message-----
From: Frederick M Avolio [mailto:fred () avolio com]
Sent: Tuesday, January 07, 2003 9:15 AM
To: Talisker; focus-ids () securityfocus com; ids () mailman vet com au
Subject: Re: [IDS] IDS Common Criteria



> Outside Government and Military circles where I can see Common Criteria
> Certification being extremely useful,  how valuable is it, ie within
the
> financial sector etc ?  More importantly what are it's failings?

CAVEAT: My direct knowledge of the CC is about 2 years old. Maybe things

are better. I doubt it.

The Common Criteria has all the markings of what it is: a government 
created and organized, committee deliberated, process. (That's meant to
be 
really negative, for those who like such things, and exclaimed, "Cool!")

Notice the definition on their web page: "The Common Criteria represents

the outcome of a series of efforts to develop criteria for evaluation of
IT 
security that are broadly useful within the international community."

The "warning signs" are "series of efforts" and "broadly useful." (And
it 
is over 600 pages.) The CC is a standard for measurement. But there is
no 
"Firewall test," not "IDS test," etc. As long as you understand that it
is 
a set of specific criteria in standard format against which a vendor can

document any product, there is no problem.

Example: If we had such a thing for automobiles, you'd be able to lay a 
chart for every one next to the other and compare across for the things
you 
cared about. They would all use standard notation for the same features.

Wait... that sounds really useful.  Yes, except -- using the example I
just 
gave -- you have to create the tables and you have to know the code name

for each feature. Oh, and the manufacturer gets to decide what features
to 
highlight and what to leave out. There is no requirement to include and 
specific criterion. It is *not* a Consumer Reports (sorry, I realize
some 
of you don't know what I mean) evaluation of products with identical 
selection criteria reporting how each product fared.

Is Common Criteria useful? I don't see how it is.

Fred
Avolio Consulting, Inc.
16228 Frederick Road, PO Box 609, Lisbon, MD 21765, US
+1 410-309-6910 (voice) +1 410-309-6911 (fax)
http://www.avolio.com/