RE: Behavior analysis vs. Integrity analysis [was: Binary Brutefo rcing]

[Michael Wojcik <Michael.Wojcik () microfocus com>]

> From: auto12012 auto12012 [mailto:auto12012 () hotmail com]
> Sent: Thursday, March 28, 2002 3:55 PM

> I cannot tell if it will cause proper behavior in all cases, but I can
> tell if it might not, and under which set of conditions it might not,
> and if this set of conditions, regardless of possible or not, can be 
> driven by untrusted interests, without having to follow the path
> itself. That covers the complete range that forms the notion of
> 'vulnerability'. (as I, and I believe a majority of people, define it)

Well I, for one, think you have a rather impoverished conception of
"vulnerability".  And I'd like to see some evidence that that's how "a
majority of people" (or "most people", as you claim later) define it.  I see
plenty of security experts using some variation on "a secure program does
what it is supposed to do, and nothing else"; the corresponding definition
of "vulnerability" would be any mechanism by which a program could be made
to exhibit insecure behavior.

Note that under such a definition what constitutes a secure program, or a
vulnerable one, cannot be determined by program logic alone, because the
metric is extra-computational: "supposed to do" requires supposition, which
is not a feature of logic.  A program that is logically correct in its trust
partitioning of data flows can still present a vulnerability to the security
of the system as a whole.  Accident is the obvious example: if a trusted
user can accidentally remove important data, for example, then the system
has a vulnerability in the form of insufficient protection against mistakes.
(Note further that it's easy to extend this kind of vulnerability into one
where active malice leads to a breach, for example through social
engineering.  The malicious data flow can be decoupled from the vulnerable
program.  It would be quite a stretch to call that "driven by untrusted
interests" - and if you're willing to do so, then no data flow can be
guaranteed untainted.)

In practice, of course, it's infeasible to vet most software against every
possible threat, to test every possible state.  But good professionals
recognize the limitations of various analysis techniques and do what they
can; they don't declare that one magic bullet reveals all possible
weaknesses.  Particularly not by narrowing definitions to suit the
capabilities of the tools they promote.

Michael Wojcik
Principal Software Systems Developer, Micro Focus
Department of English, Miami University