[prev in list] [next in list] [prev in thread] [next in thread] 

List:       focus-ids
Subject:    RE: [IDS] IDS Common Criteria
From:       Randy Taylor <gnu () charm ! net>
Date:       2003-01-22 19:32:59
[Download RAW message or body]


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) ---


[prev in list] [next in list] [prev in thread] [next in thread]