On 7/20/06, Andrew van der Stock [EMAIL PROTECTED] wrote:
Actually, it is a myth.
For every non-trivial system, there are business pressures on
resourcing, deadlines, and acceptable quality (pick any two). Once a
business has set their taste for risk, it makes no sense to spend say
$10m on
yeah.
but none of this changes the fact that it IS possible to write
completely secure code.
-- mic
And it IS possible that a man will walk on Mars someday. But its not
practical or realistic in the society we live in today. I'm sorry mic,
but I have to disagree with you here.
It is EXTREMELY
* der Mouse:
Absolute security is a myth. As is designing absolutely secure
software.
I have high hopes in formal methods.
All formal methods do is push bugs around. Basically, you end up
writing in a higher-level language (the spec you are formally verifying
the program meets). You
* Brian A. Shea:
My slogan:
Unsecured Applications = Unsecured Business
Which is completely acceptable if you and your business partners are
aware of the risk level at which your are running your company.
Secure software costs more, requires more user training, and fails in
Dana,
Regarding your remarks about writing perfectly secure code...
well put.
And your remarks about Ross Anderson...
Ross Anderson once said that secure software engineering is about
building systems to remain dependable in the face of malice, error,
or mischance. I think he has something
Hi guys!
A few days ago, following the announcements by Dan from Websense and then
HD, I wrote a post covering what they have done and what the future may
gold for Google hacking for security purposes.
http://blogs.securiteam.com/index.php/archives/513
Today a guy posted a blog on using the
On 7/20/06 11:58 AM, Florian Weimer [EMAIL PROTECTED] wrote:
* der Mouse:
Absolute security is a myth. As is designing absolutely secure
software.
I have high hopes in formal methods.
All formal methods do is push bugs around. Basically, you end up
writing in a higher-level
I'm afraid that's not true. John Knight has a famous paper that shows that
design/requirements bugs persist in n-version programming paradigms. I'll let
the interested people google that one up for themselves.
gem
company www.cigital.com.
podcast www.cigital.com/silverbullet
book
On 7/20/06 1:57 PM, Gary McGraw [EMAIL PROTECTED] wrote:
I'm afraid that's not true. John Knight has a famous paper that shows that
design/requirements bugs persist in n-version programming paradigms. I'll let
the interested people google that one up for themselves.
gem
But it's true
On 7/20/06 3:46 PM, Florian Weimer [EMAIL PROTECTED] wrote:
* Pascal Meunier:
But it's true for stupid bugs like buffer overflows and format string
vulnerabilities, in which we're still swimming, and the proof is the fact
that those aren't possible in some languages.
Could you name a
On 7/20/06 3:11 PM, Florian Weimer [EMAIL PROTECTED] wrote:
* Pascal Meunier:
Also, writing it twice with different languages, especially at different
levels of abstraction, makes it less likely that the same bugs will appear
in both.
Algorithmic issues such as denial of service
At 9:46 PM +0200 7/20/06, Florian Weimer wrote:
* Pascal Meunier:
But it's true for stupid bugs like buffer overflows and format string
vulnerabilities, in which we're still swimming, and the proof is the fact
that those aren't possible in some languages.
Could you name a few such language
12 matches
Mail list logo
