|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
RE: [IDS] IDS Common Criteria
Date: Fri Jan 10 2003 - 19:14:53 EST
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/
Received on Sun Jan 12 15:47:39 2003
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:01:05 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |