[Owasp-dotnet] RE: 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code

[dinis at ddplus.net (Dinis Cruz)]

Eric Swanson wrote:
> > What we need now is focus, energy and commitment to create a business
> environment where it is possible (and profitable) the creation,
> deployment and maintenance of applications executed in secure sandboxes.
>
>  
>
> Traditionally, the quickest answer to a need like this is terrorism of
> some kind to get people to "wake up" to imminent threats.  But, since
> we're in the business of only helping and not hurting...
true, but the issue here is that the solution for this problem is not
simple and will take a huge amount of effort and focus from all parties
involved. So the later we start the process the more painful it will be.

We have been lucky so far that the number of attacker(s) with both
intent, technical capability, business-process understanding and
opportunity have been very small. It is still also hard today to make
huge amounts of money with digital assets (for example a data center)
without using extortion or blackmail (I call this the 'monetization of
digital assets')

So what you need to do is ask the question "Will the current rate of
security enhancements that we are doing to our systems will be higher
than the rate of growth in the attacker(s): numbers (as in quantity),
skills, ability to monetize digital assets and opportunity".

If those two lines (the 'security enhancements' and the 'attacker(s)
profile') don't cross (situation we live in today), we are ok. But if
the lines do cross over, then we will have a major crisis in our hands.
> How do we motivate management decisions to support developing more
> secure solutions?
You make them aware of the 'reality' of the situation, and the
consequences of the technological decisions they make everyday (i.e.
make them aware that the CIA (Confidentiality, Integrity and
Availability) or his/hers IT systems is completely dependent on the
honesty, integrity and non-malicious intent of thousands and thousands
of individuals, organizations and governments.
>   It's the same question as motivating better problem definitions,
> code requirements gathering, documentation, refactoring, performance
> optimizations, etc.  Time and budget.  The answer is to have an
> affordable, flexible development process and tools that support these
> motivations.
For me (a key part of) the answer is to have an/ '...affordable,
flexible development process and tools that support...' /the creation of
applications which can be executed in secure partial trust environments :)
> In .NET, code reflection and in-line XML comments coupled with
> formatting tools like "NDoc" made professional code documentation an
> instant option available to every .NET developer, even those on a
> shoe-string budget.
Yes, but unfortunately it also made development partially trusted code
very expensive
>  
>
> The answer from OWASP might be to re-evaluate development processes
> and develop both sandboxes for clients as well as security patterns,
> components, wizards, and utilities for developers. 
We could do that, but we would need much more resources that the ones we
currently have (and until Microsoft joins the party, it will be a
pointless exercise)
> We could re-write development processes like the hot topics "Agile
> Development" and "Extreme Programming" to include the SSDL, "Secure
> Software Development Lifecycle".  Perhaps we should be making a better
> business case for the SSDL, like the 2^nd Edition of Code Complete's
> "Utterly Compelling and Foolproof Argument for Doing Prerequisites
> Before Construction" (Print ISBN: 0-7356-1967-0).
Agree. I am a big fan of SSDL and believe that it is an integral part of
the environment required to create secure applications
> Our guides and vulnerability detection utilities just scratch the
> surface. 
Yes, and also (specially the tools) show how little interest there is in
this topic
> The utilities in particular do not directly address our concerns for
> motivating the community, except by opening the eyes of the developers
> who actually use them and giving them something fun to play with.
even then, most developers and managers don't have the security
experience to understand the implications of the security issues
highlighted by these tools (and when they do, they find that there is no
market for securer apps/hosting environments)
> Given the many options that lay ahead of the group, my opinion would
> be to work on better incorporating the SSDL into popular development
> processes and making a clear-cut business case (with statistics) for
> its inclusion.  To motivate participation, we continue to develop the
> utilities, patterns, components, and wizards for developers (both
> before and after the development release cycle).  Perhaps we take the
> online guides, checklists, and utilities and begin to formulate what
> SSDL looks like through OWASP's eyes.
That's the plan :)

Very soon we (Owasp) should be making an announcement which will talk
about this

Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060406/0ae87501/attachment.html