IDS mailing list archives
RE: [IDS] IDS Common Criteria
From: Randy Taylor <gnu () charm net>
Date: Wed, 22 Jan 2003 14:32:59 -0500
List admin - This apparently bounce off your Qmail system because of timeout. I am resending. If the bounce message I received was in error, please disregard. Thanks, Randy At 01:37 PM 1/17/2003 -0500, Graham, Robert (ISS Atlanta) wrote:
From: Randy Taylor [mailto:gnu () charm net] >I agree with you that CC and a process-oriented security approach >are different "things" in and of themselves. They are the same. It seems you haven't understood either of my previous messages (sorry, I probably phrased them poorly). My argument is essentially: Common Criteria Evaluation is an example of good process, but it is generally bad -- therefore process is generally bad. When cryptographers say "security is a process", the type of processes they are referring to are those like Common Criteria Evaluation. I have a hard time understanding how somebody can be "for" process, but "against" processes like CC. The crux of the problem is what economists call "decreasing marginal returns". A small amount of lightweight processes give you more benefit than they cost. A large amount of heavyweight processes (like CC) give you marginal benefits but cost a huge amount. If you are the military or intelligence organization (the guys cryptographers generally design cryptography for), then you are willing to spend that much for small improvements. If you are everyone else, then you can't afford it. The military has secrets that are worth more than your entire organization (and you don't).
Ok, now I see what your point is. I felt like we were talking past each other - it wouldn't have been the first time. ;) Yes, CC is a heavyweight process. It was developed in an arena in which heavy process is the norm, e.g., the intel community and the world of "formal security" methods. I've been lucky in my career in that I've had the chance to work on projects that involved both formal security and practical security. I've worked with everything from the early 1993 B1+ CMW systems like SecureWare and Trusted Solaris to fighting hackers real-time when they'd take down a new IRIX or SunOS box within 15 minutes of it going up on our net. Things like NFSShell and WaterWorks were the bane of my existence for a while there. :-/ I guess my point is that in the early days formal security never made much of an impact on the real world. So I discounted formal security from having any practical value. Ever try to get anything approaching real work done on a Compartmented-Mode Workstation? It wasn't until mid-2001 that I started seeing requirements for Common Criteria certification in order to sell security product. "Great", I thought, "this is going to be a total kludge. This will do nothing to improve real-world security." I was wrong. CC had come a long way from its Orange Book origins. It was still a pain in the backside from the vendor perspective, and it still wasn't perfect in anyone's view, but it really had improved in the eight years since I last gave it any serious thought. Sure, CC still has its faults, but NSTISSP No. 11 has opened up a very healthy debate about what does and does not work when formal security meets practical security head-on. For the end-user/purchaser of security products, CC is or will become a check-box - "Product X is rated CC EAL 3, which fits our requirements. *check*" and on to the next check-box. It's the product vendors that shoulder the burden of getting that certification. The initial and life-cycle costs of that effort gets passed along to customers per-unit sold at a substantial markup via "value-add" marketing. ;)
A small amount of process is worth the cost. However, many have jumped on "security is a process" in order to burden their organizations with overweight processes. Moreover, narrow minded bureaucrats often use "security is a process" to prevent talented/educated people from actually getting their job done -- with a detriment to an organization's security. I see organization after organization where process is the enemy of security.
Yeah...that happens, but it's not just in the security field. Otherwise the Dilbert comic strip would not exist. ;) Sticking with security, though, I'm seeing customers that need process because of the size and complexity of the networks they are building. In those cases, process keeps everyone pretty close to the same page at all times - and everyone involved recognizes the need for process as well. Maybe for every negative story there's a positive one.
Disagreement on semantics is one of the most boring debates on technology forums. It is quite possible that you and I agree on the core problem except for the semantics: i.e. you describe reasonable processes and express a distaste for heavyweight processes. My goal isn't to convince you of my semantics. My goal is to give ammunition to the talented security engineer who is stopped by stupid people who insist on controlling their actions with yet more process, because Bruce Schneier says that process is the end-all/be-all of security. I find it curious that there are lot of people who know little about security, yet they insist that they should be the ones creating more process to constrain the actions of those who do. I have met a lot of frusterated security professionals out there who have expressed these same sentiments.
As I said above, we've probably talked past each other, and we've been down that road before. To close out my comments on CC, I think it's a necessary process right now. I look for it to grow out of U.S. .mil and .gov space and into .com pretty soon. CC is far from perfect, but I think it will improve over time. "Security is a process", ala Schneier, is an essentially correct way of thinking, but it should not take the place of good old common sense. I am absolutely not a fan of process at the expense of reason. When process methods work, use them. When they don't work, recognize it early and find better answers. The answers you'll find then become new process - rinse, repeat. I really can't think of anything else to say on this topic, so I'll step out of the thread here. Best regards, Randy ----- "If we want things to stay as they are, things will have to change." -- Giuseppe Tomasi di Lampedusa "The Leopard" (1958) ---
Current thread:
- RE: [IDS] IDS Common Criteria Graham, Robert (ISS Atlanta) (Jan 12)
- <Possible follow-ups>
- RE: [IDS] IDS Common Criteria Randy Taylor (Jan 15)
- RE: [IDS] IDS Common Criteria Rob Shein (Jan 19)
- RE: [IDS] IDS Common Criteria Randy Taylor (Jan 16)
- RE: [IDS] IDS Common Criteria Rob Shein (Jan 19)
- RE: [IDS] IDS Common Criteria Graham, Robert (ISS Atlanta) (Jan 17)
- RE: [IDS] IDS Common Criteria Parnelli Vondel (Jan 20)
- RE: [IDS] IDS Common Criteria Graham, Robert (ISS Atlanta) (Jan 21)
- RE: [IDS] IDS Common Criteria Randy Taylor (Jan 23)