Comments: H5: Security Begins at the Application and Ends at the Mind

for the fun of it, something from yesterday in the cryptography mailing list
http://www.garlic.com/~lynn/2009c.html#25 Crypto Craft Knowledge

that mentions several "end-to-end" audit/issues ... including doing some reviews where trivial exploits were found ... and being told that wasn't part of the security protocol.

Posted by Lynn Wheeler at February 15, 2009 02:20 PM

lol... I saw your post, as well as the various attempts to re-define CAs as mathematically provable functions. Actually I should have been working on the "audit" series of posts this evening, but got distracted. I haven't really considered audit from an end-to-end perspective, but it certainly fits. Defining things "inside" and "outside" scope until the model suits our sense of elegance seems to be the common design paradigm.

Posted by Iang at February 15, 2009 02:29 PM

Having been involved in business critical dataprocessing for a couple decades ... clients typically cared whether there was any kind of fault/failure ... and only secondarily (if at all) cared about how/what.

Only focusing on some moderately trivial portion of end-to-end problems ... seemed frequently to be part of "hype" promoting some specific (possibly security) solution or market.

The start of the crypto craft thread was somewhat about limited breadth of knowledge to recognize all possible ways things might fail (but still limited to crypto or security specific issues).

In business critical dataprocessing ... an issue was *ALL* possible kinds of faults or failures. *ALL* somewhat translates into "end-to-end" when approaching the subject from a communication or networking perspective.

I've mentioned several times in the past ... we had been asked to consult with small client/server startup that wanted to do payments on there server and they had this technology they had invented called SSL they wanted to use.

As part of that effort, we had to go around and look at several of these new things calling themselves Certification Authorities. One of the insights was that many of the principles in these early efforts had come from mathematical or technical background. Most admitted that they were surprised to learn that only about 5% of a CA is technical ... 95% of a CA is bookkeeping, administration, filing, ... traditional business operation.

Mathematical provable is a really small part of the overall operation and ... raising that issue may even sometimes be misdirection.

For a slightly different perspective on Financial dataprocessing
http://www.garlic.com/~lynn/2008p.html#2 Father of Financial Dataprocessing

old email regarding when he was leaving SJR for Tandem and turning over a lot of his responsibilities to me:
http://www.garlic.com/~lynn/2009c.html#email801016
in this post
http://www.garlic.com/~lynn/2007.html#1

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

Posted by Lynn Wheeler at February 15, 2009 03:26 PM

oops, finger slip that was:
http://www.garlic.com/~lynn/2007.html#email801016

Posted by Lynn Wheeler at February 15, 2009 03:31 PM

Confused by the applicability of this particular hypothesis (and in general all of them)...

Are you primarily concerned with over the wire comms, especially outside the 'boundaries' (whatever they are) of an organisation's network?

If not, then would App to DB communication fall in its remit? H5 is pretty much broken in this space afaik, as such communication IS dependent on underlying infrastructure/ protocols to a great extent.. Unless you suggest that the app encrypt everything apart from the SELECT WHERE FROM etc in the SQL...

Posted by AC2 at February 16, 2009 03:05 AM

The recent focus on application security is confusing.

You say 'only application security is worthwhile', yet the National Security Agency have observed current security efforts suffer from the flawed assumption that adequate application level security can be provided by existing security mechanisms running under insecure mainstream operating systems.1 They conclude that in reality secure applications require secure operating systems, and that all efforts to provide application level security without secure operating systems are doomed to fail. This was stated in the following 1998 paper, which all links to seem to have dried up:

The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments, by Peter A. Loscocco, Stephen D. Smalley, Patrick A. Muckelbauer, Ruth C. Taylor, S. Jeff Turner, and John F. Farrell.

With this consideration, a preferred model would probably be along the lines of OS security that monitored into the application stack. The trick then, would be to provide usability.

Posted by Rob Lewis at February 17, 2009 11:17 AM
Post a comment









Remember personal info?






Hit Preview to see your comment.
MT::App::Comments=HASH(0x55953e64b448) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/Object.pm line 125.