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:
> One further question:  Can we ever really advise developers on how to
> develop secure code when the foundations they are developing on top of
> are inherently insecure? 
Yes we can, as long as each layer creates/implements a secure sandbox
for the one above it.

So if each layer acts responsibly and creates a securer environment for
one build on top of it, then yes it makes sense to write secure code at
all levels (think 'Defense in Depth', 'Sandboxing', 'Sandbox inside a
Sandbox', privilege isolation, etc...)
> If the answer is ultimately no (without re-writing the end-client OS
> or execution framework), we must then consider the question, how can
> we make a good business case for developing secure solutions when,
> ultimately, the secure solution can be compromised?
There will always be a way to compromise an asset. Our job is to make
that exploit/attack: very hard to execute, very easy to detect and with
limited damage

This will scale up because the focus will be on creating secure
Sandboxes (i.e. run-time environments) instead of writing code with no
bugs and security vulnerabilities. The first one (Sandboxing) is hard
but doable, the 2nd one (code with no bugs) is probably impossible.
Another benefit will be the separation of responsibility and
accountability: the security consultants will be worried about the
Sandboxes security and the developers will be focused on features and
functionality (the security consultants are paid by the clients, and the
developers paid by the software vendor).

Note that the interfaces between layers (i.e. the APIs exposed by the
Sandbox) reduce the number of possible interconnections between multiple
components, and dramatically simplify the job of identifying normal
behavior (which necessary in order to be able to identify malicious
behavior). Note that I don't think that one will ever be able to
accurately certify that an application written in unmanaged code doesn't
perform a certain malicious activity. But I do believe that it will be
possible to make that assertion about managed and verifiable code
designed to execute in a secure partial trust environment.
> Complete security is never the ultimate destination, but rather
> mitigating risk through any acceptable means...
Absolutely, but when you have to trust 100% of the executed code, the
'only' mitigation activity that you can do is to prevent malicious code
from being executed in the first place (which is close to impossible in
today's computing environment).

Our current risk mitigation strategy seems to be reliant on the reduced
number of attackers and the large number of assets.

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