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

[Mark C. <ma...@cu...>]

Alex

You're a man after my own heart ;-)

Models like Biba and Bell la Padula should have taught us far more than
appears to have been the case !

1. Monolithic kernels - great example  

2. Agreed. remember you don't have to feed the world from day one. Why
not define requirements and then prioritize them ? lower priorities can
be dealt with in release 2.0 etc

3.  Agree. I would have thought that something more than good
documentation seems appropriate. I can get you help with that when the
time comes.

So why not take this approach ?

(This is based on the RUP - Rational Unified Process). 

1. Develop a Vision Document

http://www.rational.com/media/worldwide/singapore/introducing_processes.pdf is one example on the web but you'll find lots. The vision document include features not requirements. It includes short sections on the problem we are trying to solve, objectives, risks, resources etc

2. Develop a set of prioritized requirements

3. From the requirements develop your use cases and move on.

Remember iterative development works better than waterfall development
as well.

I can help with this sort of stuff if you want. 

I can certainly take a first step at a Vision document on Friday. Just
let me know !

On Wed, 2002-06-26 at 17:00, Alex Russell wrote:
> 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...