[Owasp-input-api-developers] considerations with regards to development

[Alex R. <al...@se...>]

Hey everyone,

I can't help but think that we keep falling off track in our focus on 
this project. We haven't even completed discussion about the threat 
model or security targets yet but we keep getting drawn into discussions 
about design. To help clarify a bit, I submit the following general 
principles for your review.

Often I feel that we are treating the project as just another software 
development project. Security critical software development MUST be 
different from "normal" software development in a couple of ways (I'll 
explain the reasons as I go).




1.) Simple wins.

In "traditional" software development, features win. The product that
implements the most features will seem to be the most attractive and
therefore will sell/distribute the most copies. Combined with first
mover and network advantages, the features==market share equation has
been slowly ingrained into the minds of software developers the world
over. In the security world, this axiom breaks completely.

The enemy of security is complexity (in all of its forms). That which
is harder to do is that much harder to do correctly, and when it comes
to security, we have seen spectacular failures over and over again
because this principle has been broken. The most successful security
products (OpenBSD, MULTICS, etc.) all have one thing in common: they
do things in simple, obvious ways that my be neither either fast nor
elegant, but they work... and work... and work...

The trend towards kernilization of security features is a direct result
of this maxim, because it can allow developers to significantly decrease
the size of the Trusted Computing Base (TCB), which can then be verified
much more thoroughly. Systems such as tmach, NT, etc, all make use of
this principle in the design of their security-critical subsystems. The
larger the TCB (more code running with privileges), the higher the
probability that attacks will be successful (as witnessed by IIS). Those
familiar with the principle of least privledge may appreciate the
simplicity axiom as a restatement or a generalization of that principle.

This axiom suggests that it may be desirable to consider "simple and
verified" superior to "elegant and flexible" in the design of our
toolkit.



2.) Defend against what is likely, not what is possible.

This runs counter to the normal software development practice of
feature-focused development. When it comes to security, priorities
must be set in what threats will be considered and dealt with as
security be determined by the "does it compile and run?" test.

If a defender spends 50% of his time defending a threat that has an
incidence coefficient of 0.0002 but a damage (monetary loss, whatever)
of 50,0000 but only spends 10% of his time defending against a problem
with an incidence of 5 but with a damage of "only" 5, is he doing the
right thing?

Clearly not.

While the threat with incidence of 0.0002 may be technically
interesting, it is clearly not the source of most loss, and so should be
given appropriate priority when crafting a defense.

This rule suggests that when drafting a threat model and security
target, it is highly desirable to consult data about the attacks
(frequency, success rates, mitigation factors) carried out against
systems currently in production in the same or similar veins.



3.) The human factor cannot be ignored.

Software developers are notorious for just throwing things on
interfaces, betraying a lack of understanding (or interest) in how end
users will wind up using the interfaces they produce. Security design
challenges this assumption by recognizing that humans are the weakest
link in most security sensitive systems.

Like it or not, humans are involved in almost every security-critical
system. An allegory to point #1, the fact that human are involved
suggests that human error can be a significant risk factor and so should
be dealt with in the use and operation of security critical systems. In
the case of our project, this may suggest that it is highly desireable
to distribute some form of education/training/awareness material with
the toolkit.



4.) Environments Change

Assumptions made about environmental factors must be either overt (the
system cannot function with out it) or constantly checked
(assumption==valid or die), as a change in one of these assumptions in
all likelihood _will_ undermine the security engineered into an
application or product. Take, for instance, the case of ATM machines. At
one point, cryptography for ATMs was handled by an "exchange" box that
was external to the ATM itself. This machine handled the communication
between the bank and external networks. The assumption here was that
such machines would be physically close to an ATM because ATMs were
simply too expensive to place outdoors or have more than one at any
branch.

When the price of ATMs fell dramatically, they started to be placed in
many locations not accounted for by this assumption. Yet in some
systems, encryption was still carried out in the central exchange
machine located in the bank branch, meaning that ATMs not near the bank
were transmitting information in the clear for possibly miles.
Environmental assumptions that were not explicitly designed in such a
way as to break the system when they changed. As a result, very insecure
systems were built on top of what was once a demonstrably secure
infrastructure.




I believe that unless we (as a team) use these axioms in judging the
quality of a design/implementation for our project, we may wind up
creating a really whiz-bang toolkit that doesn't do very much to ease
the burden of developers in creating secure web applications.

So what does everyone else think? Can we develop with these principles?

-- 
Alex Russell
al...@Se...
al...@ne...