Re: [SC-L] Bumper sticker definition of secure software

2006-07-24 Thread Dana Epp
But secure software is not a technology problem, it's a business one.
Focused on people.

If smartcards were so great, why isn't every single computer in the
world equipped with a reader? There will always be technology safeguards
we can put in place to mitigate particular problems. But technology is
not a panacea here. 

There will always be trade-offs that will trump secure design and
deployment of safeguards. It's not about putting ABSOLUTE security in...
It's about putting just enough security in to mitigate risks to
acceptable levels to the business scenario at hand, and at a cost that
is justifiable. Smartcard readers aren't deployed everywhere as they
simply are too costly to deploy, against particular PERCEIVED threats
that may or not be part of an application's threat profile.

I agree that we can significantly lessen the technology integration
problem with computers. We are, after all, supposed to be competent
developers that can leverage the IT infrastructure to our bidding. The
problem is when we keep our head in the technology bubble without
thinking about the business impacts and costs, wasting resources in the
wrong areas.

It is no different than network security professionals that deploy
$30,000 firewalls to protect digital assets worth less than the computer
they are on. (I once saw a huge Checkpoint firewall protecting an MP3
server. Talk about waste.) Those guys should be shot for ever making
that recommendation. As should secure software engineers who think they
can solve all problems with technology without considering all risks and
impacts to the business.


Regards,
Dana Epp 
[Microsoft Security MVP]
http://silverstr.ufies.org/blog/

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of mikeiscool
Sent: Sunday, July 23, 2006 3:42 PM
To: Crispin Cowan
Cc: Secure Coding Mailing List
Subject: Re: [SC-L] Bumper sticker definition of secure software

 As a result, really secure systems tend to require lots of user 
 training and are a hassle to use because they require permission all
the time.

No I disagree still. Consider a smart card. Far easier to use then the
silly bank logins that are available these days. Far easier then even
bothering to check if the address bar is yellow, due to FF, or some
other useless addon.

You just plug it in, and away you go, pretty much.

And requiring user permission does not make a system harder to use (per
se). It can be implemented well, and implemented badly.


 Imagine if every door in your house was spring loaded and closed 
 itself after you went through. And locked itself. And you had to use a

 key to open it each time. And each door had a different key. That 
 would be really secure, but it would also not be very convenient.

We're talking computers here. Technology lets you automate things.


 Crispin

-- mic
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-24 Thread Andrew van der Stock
NB: I am not speaking on behalf of my employer and this is my  
personal opinion.


Banks in general do not use smart cards as they suffer from the same  
issue as two factor non-transaction signing fobs - they are somewhat  
trivial to trick users into giving up a credential. Connected keys  
are the worst - they induce laziness in the user and infer security  
which is not actually there.


Smart card integration over web apps is non-existent. The HTTP 1.1  
protocol does not support two factor transaction signing nor smart  
cards in general (unless you are just using SSL with a client-side  
cert, which is just as vulnerable as a normal IB app today if the  
attacker chooses a CSRF attack). Therefore, you need *something*  
extra to make 2FA USB fob authentication work. RSA has an ActiveX  
plugin (Keon WebPassport) which works great in an Intranet  
environment and you control all the resources. However, such  
solutions have a support overhead and locks users into just Win32  
platform, and locks out pretty much any site that blocks ActiveX  
controls on their PCs.


Here's why such devices will not fly:

*) costs money to ensure that the crypto is compliant with national  
and international standards
*) costs money to develop and deploy secure internal PKI and secure  
operational procedures to issue certificates for the devices. For the  
average institution, this is a lot of overhead.
*) costs money to deploy (need to send out software, instructions,  
device, smart card)
*) costs money to register users securely (is sending through the  
mail acceptable?) - this step was stuffed up in the UK's Chip and  
Pin roll out, so we have an excellent data point already


http://www.theregister.co.uk/2004/09/16/chip_pin_crime_wave/

*) costs money to train users to only insert their smart card when  
your app is running and not just leave it in
*) costs money to support users when your software gets the blame for  
their user's support woes (whether true or not)

*) doesn't improve security if the user can just say yes.

The typical dialog for these things is Please press Submit to pay  
Nice Person $100 using your token. If the app suffers from an XSS,  
why is this prompt safe? Can you trust Nice Person or $100?


Disconnected trx signing devices are simple, cheap, and have *fewer*  
costs. Note I do not say none of the costs, but it is significantly  
less and at least we don't trust the user's browser, the user's  
browser can be any platform (MacOS X, Linux, FreeBSD, Win95, XP,  
Vista), we don't end up supporting the user's desktop, and we don't  
need to train the users so much.


That's why smart cards will not be used if the Bank has done a proper  
side-by-side comparison, and compared the relative risk versus cost.  
Smart cards (and anything which requires platform support) are less  
secure, less trustworthy, take more effort, and cost more.


thanks,
Andrew

On 23/07/2006, at 3:42 PM, mikeiscool wrote:


No I disagree still. Consider a smart card. Far easier to use then the
silly bank logins that are available these days. Far easier then even
bothering to check if the address bar is yellow, due to FF, or some
other useless addon.




smime.p7s
Description: S/MIME cryptographic signature
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-21 Thread mikeiscool
On 7/21/06, Florian Weimer [EMAIL PROTECTED] wrote:
 * 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
 hard-to-understand patterns.  If you really need it, you lose.

Really secure software should require _less_ user training, not more.

-- mic
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-20 Thread Florian Weimer
* 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
hard-to-understand patterns.  If you really need it, you lose.
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-18 Thread Rajeev Gopalakrishna
Reliability is concerned only with accidental failures while security has
to consider malicious attacks as well. The difference is in the intent of
the software user: benign or malicious.

And for a bumper sticker, here is one for the pessimists:

Secure Software is a Myth

and another version for the skeptics:

Is Secure Software a Myth?

:)

-rajeev


On Mon, 17 Jul 2006, Peter G. Neumann wrote:

 You suggest:

   Secure software is software that remains dependable despite efforts to
   compromise its dependability.

 You need a bigger-picture view that encompasses trustworthiness
 and assurance.

 Dependable systems are systems that remain dependable despite
 would-be compromises to their dependability.

 Trustworthy systems are systems that are worthy of being trusted
 to satisfy their requirements (for security, reliability, survivability,
 safety, or whatever).

 Security is generally too narrow by itself, because a system that is
 not reliable is not likely to be secure, especially when in
 unreliability mode!

 The principle of Keep It Simple is inherently unworkable with respect to
 security.  Security is inherently complex.  Trustworthiness is broader and
 even more complex.  But if you don't think about trustworthiness more
 broadly, what you get is not likely to be very secure.

 Forget the bumper sticker approach.

 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-18 Thread Gadi Evron
On Mon, 17 Jul 2006, Rajeev Gopalakrishna wrote:
 Reliability is concerned only with accidental failures while security has
 to consider malicious attacks as well. The difference is in the intent of
 the software user: benign or malicious.
 
 And for a bumper sticker, here is one for the pessimists:
 
 Secure Software is a Myth
 
 and another version for the skeptics:
 
 Is Secure Software a Myth?
 
 :)

Again, this would speak only to a very small percentage of the
population. You me, maybe 10K people around the world if we are generous.

 
 -rajeev
 
 
 On Mon, 17 Jul 2006, Peter G. Neumann wrote:
 
  You suggest:
 
Secure software is software that remains dependable despite efforts to
compromise its dependability.
 
  You need a bigger-picture view that encompasses trustworthiness
  and assurance.
 
  Dependable systems are systems that remain dependable despite
  would-be compromises to their dependability.
 
  Trustworthy systems are systems that are worthy of being trusted
  to satisfy their requirements (for security, reliability, survivability,
  safety, or whatever).
 
  Security is generally too narrow by itself, because a system that is
  not reliable is not likely to be secure, especially when in
  unreliability mode!
 
  The principle of Keep It Simple is inherently unworkable with respect to
  security.  Security is inherently complex.  Trustworthiness is broader and
  even more complex.  But if you don't think about trustworthiness more
  broadly, what you get is not likely to be very secure.
 
  Forget the bumper sticker approach.
 
  ___
  Secure Coding mailing list (SC-L)
  SC-L@securecoding.org
  List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
  List charter available at - http://www.securecoding.org/list/charter.php
 
 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-18 Thread Paolo Perego
Hi list, I'll introduce myself with a claim:
Software is like Titanic, pleople claim it was unsinkable. Securing is providing it power steering 

thesp0nge
On 7/18/06, Gadi Evron [EMAIL PROTECTED] wrote:
On Mon, 17 Jul 2006, Rajeev Gopalakrishna wrote: Reliability is concerned only with accidental failures while security has
 to consider malicious attacks as well. The difference is in the intent of the software user: benign or malicious. And for a bumper sticker, here is one for the pessimists: Secure Software is a Myth
 and another version for the skeptics: Is Secure Software a Myth? :)Again, this would speak only to a very small percentage of thepopulation. You me, maybe 10K people around the world if we are generous.
 -rajeev On Mon, 17 Jul 2006, Peter G. Neumann wrote:  You suggest:   Secure software is software that remains dependable despite efforts to
  compromise its dependability.   You need a bigger-picture view that encompasses trustworthiness  and assurance.   Dependable systems are systems that remain dependable despite
  would-be compromises to their dependability.   Trustworthy systems are systems that are worthy of being trusted  to satisfy their requirements (for security, reliability, survivability,
  safety, or whatever).   Security is generally too narrow by itself, because a system that is  not reliable is not likely to be secure, especially when in  unreliability mode!
   The principle of Keep It Simple is inherently unworkable with respect to  security.Security is inherently complex.Trustworthiness is broader and  even more complex.But if you don't think about trustworthiness more
  broadly, what you get is not likely to be very secure.   Forget the bumper sticker approach.   ___  Secure Coding mailing list (SC-L)
  SC-L@securecoding.org  List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
  List charter available at - http://www.securecoding.org/list/charter.php  ___ Secure Coding mailing list (SC-L)
 SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - 
http://www.securecoding.org/list/charter.php___Secure Coding mailing list (SC-L)
SC-L@securecoding.orgList information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList charter available at - 
http://www.securecoding.org/list/charter.php-- $cd /pub$more beerAngeL core developer: http://www.sikurezza.org/angel
 
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-17 Thread Crispin Cowan
mikeiscool wrote:
 On 7/17/06, Crispin Cowan [EMAIL PROTECTED] wrote:
   Goertzel Karen wrote:
  I've been struggling for a while to synthesise a definition of secure
  software that is short and sweet, yet accurate and comprehensive.

 My favorite is by Ivan Arce, CTO of Core Software, coming out of a
 discussion between him and I on a mailing list about 5 years ago.

 Reliable software does what it is supposed to do. Secure software
 does what
 it is supposed to do, and nothing else.
 and what if it's supposed to take unsanitzed input and send it into
 a sql database using the administrators account?

 is that secure?
supposed to goes to intent. If it is a bug that allows this, then it
was not intentional. If it was intended, then (from this description) it
was likely a Trojan Horse, and it is secure from the perspective of the
attacker who put it there.

IMHO, bumper sticker slogans are necessarily short and glib. There isn't
room to put in all the qualifications and caveats to make it a perfectly
precise statement. As such, mincing words over it is a futile exercise.

Or you could just print a technical paper on a bumper sticker, in really
small font :)

Crispin

-- 
Crispin Cowan, Ph.D.  http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
 Necessity is the mother of invention ... except for pure math

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-17 Thread Holger.Peine
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Dave Aronson
 If you really want to compress that to bumper-sticker size, how about
 
   Secure Software:  Does what it's meant to.  Period.
 
 This encompasses both can't be forced NOT to do what it's 
 meant to do, 
 and can't be forced to do what it's NOT meant to do.

While I think this is the most concise formulation so far of what 
most readers on this list would mean and would understand, I think
the non-security public does not think of security breaches in
terms of software doing more than it was supposed to. My suggestion
for a bumper sticker is therefore less conceptually crisp, but perhaps 
more accessible:

Secure Software: Works even if you try to dupe it

Nice question, though -
Holger Peine

-- 
Dr. Holger Peine, Security and Safety
Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
Phone +49-631-6800-2134, Fax -1299 (shared)
PGP key via http://pgp.mit.edu ; fingerprint is 1BFA 30CB E3ED BA99 E7AE
2BBB C126 A592 48EA F9F8

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-17 Thread mikeiscool
On 7/17/06, Crispin Cowan [EMAIL PROTECTED] wrote:
 mikeiscool wrote:
  On 7/17/06, Crispin Cowan [EMAIL PROTECTED] wrote:
Goertzel Karen wrote:
   I've been struggling for a while to synthesise a definition of secure
   software that is short and sweet, yet accurate and comprehensive.
 
  My favorite is by Ivan Arce, CTO of Core Software, coming out of a
  discussion between him and I on a mailing list about 5 years ago.
 
  Reliable software does what it is supposed to do. Secure software
  does what
  it is supposed to do, and nothing else.
  and what if it's supposed to take unsanitzed input and send it into
  a sql database using the administrators account?
 
  is that secure?

 supposed to goes to intent.

I don't know. I think there is a difference between this does what
it's supposed to do and this has no design faults. That's all I was
trying to highlight.

The point remains though: trimming this down into a friendly little
phrase is, IMCO, useless.


 If it is a bug that allows this, then it
 was not intentional. If it was intended, then (from this description) it
 was likely a Trojan Horse, and it is secure from the perspective of the
 attacker who put it there.

 IMHO, bumper sticker slogans are necessarily short and glib. There isn't
 room to put in all the qualifications and caveats to make it a perfectly
 precise statement. As such, mincing words over it is a futile exercise.

 Or you could just print a technical paper on a bumper sticker, in really
 small font :)

 Crispin

-- mic
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-17 Thread Crispin Cowan
mikeiscool wrote:
 On 7/17/06, Crispin Cowan [EMAIL PROTECTED] wrote:
 supposed to goes to intent.
 I don't know. I think there is a difference between this does what
 it's supposed to do and this has no design faults. That's all I was
 trying to highlight.
The difference between supposed to, design flaw, and implementation
flaw is entirely dependent on your level of abstraction:

* Executive: build a thingie that lets good guys in and keeps bad
  guys out.
* Director: build an authentication engine that uses 2-factor
  tokens to authenticate users and only then lets them in.
* Manager: use OpenSSL and this piece of glue to implement that
  2-factor thingie.
* Coder: main() { ... :)

Errors can occur at any level of translation. When it does something
surprising, then the guy at the top can claim that it wasn't
supposed to do that, and if you dig hard enough, you will discover
*some* layer of abstraction where the vulnerability violates the upper
intent, but not the lower intent. Hence the bug.

Some example bugs at each level:

* Executive: forgot to specify who is a good guy
* Director: Forgot to provide complete mediation, so the attacker
  could bypass the authenticator.
* Manager: the glue thingie allowed proper authentication tokens,
  but also allowed tokens with a string value of 0.
* Coder: gets(token); ...

Crispin

-- 
Crispin Cowan, Ph.D.  http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
 Necessity is the mother of invention ... except for pure math

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-17 Thread Gadi Evron
On Mon, 17 Jul 2006, Peter G. Neumann wrote:
 Forget the bumper sticker approach.

Hey Peter. :)

Well, one should forget the bumper-sticker approach if all us broing dry
guys keep try to explain to people how math works.

Instead, teling them:
1+1=?
Didn't learn math, eh?

Is bumper-sticker worthy, if pointless as an example.

In other words:
I read your email! When have you last audited your code?

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-17 Thread Peter G. Neumann
Gary, If you think security is a funny topic, try this one:

  http://haha.nu/funny/funny-math/
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-17 Thread Pascal Meunier
I prefer to define the opposite:

Insecure Software is like a joke,
Except others laugh at you

I like it because:
-it captures the notion that vulnerabilities, just like jokes, are very
often made apparent by thinking in a different context from the software's
designers (the straight man).

-It conveys the notion that insecure software is shoddy;

-It conveys the notion that there are people who will find out that you run
insecure software;

-It may motivate some people to care about security by invoking social
stigma ;)


Cheers,
Pascal Meunier
Purdue University CERIAS



On 7/15/06 3:27 PM, Goertzel Karen [EMAIL PROTECTED] wrote:

 I've been struggling for a while to synthesise a definition of secure software
 that is short and sweet, yet accurate and comprehensive. Here's what I've come
 up with:
 
 Secure software is software that remains dependable despite efforts to
 compromise its dependability.
 
 Agree? Disagree?
 
 --
 Karen Mercedes Goertzel, CISSP
 Booz Allen Hamilton
 703-902-6981
 [EMAIL PROTECTED]
 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php


___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-17 Thread Glenn and Mary Everhart
Crispin Cowan wrote:
 mikeiscool wrote:
 On 7/17/06, Crispin Cowan [EMAIL PROTECTED] wrote:
 supposed to goes to intent.
 I don't know. I think there is a difference between this does what
 it's supposed to do and this has no design faults. That's all I was
 trying to highlight.
 The difference between supposed to, design flaw, and implementation
 flaw is entirely dependent on your level of abstraction:
 
 * Executive: build a thingie that lets good guys in and keeps bad
   guys out.
 * Director: build an authentication engine that uses 2-factor
   tokens to authenticate users and only then lets them in.
 * Manager: use OpenSSL and this piece of glue to implement that
   2-factor thingie.
 * Coder: main() { ... :)
 
 Errors can occur at any level of translation. When it does something
 surprising, then the guy at the top can claim that it wasn't
 supposed to do that, and if you dig hard enough, you will discover
 *some* layer of abstraction where the vulnerability violates the upper
 intent, but not the lower intent. Hence the bug.
 
 Some example bugs at each level:
 
 * Executive: forgot to specify who is a good guy
 * Director: Forgot to provide complete mediation, so the attacker
   could bypass the authenticator.
 * Manager: the glue thingie allowed proper authentication tokens,
   but also allowed tokens with a string value of 0.
 * Coder: gets(token); ...
 
 Crispin
 
Yep...there are plenty of things that can go wrong. There are also plenty of 
rather clever attacks. Designing a system requires much more complete thought
and a comprehensive viewpoint to have a hope...

As one very very minor example consider:

Authentication only for a payment rather resembles a check with only a 
signature.

Glenn Everhart

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-16 Thread ljknews
At 3:27 PM -0400 7/15/06, Goertzel Karen wrote:
 Content-class: urn:content-classes:message
 Content-Type: multipart/alternative;
   boundary=_=_NextPart_001_01C6A844.D6A28B6B

 I've been struggling for a while to synthesise a definition of secure
software that is short and sweet, yet accurate and comprehensive. Here's
what I've come up with:

 Secure software is software that remains dependable despite efforts to
compromise its dependability.

 Agree? Disagree?

I disagree about that being bumper-sticker size, and I think we really
need bumper stickers.
-- 
Larry Kilgallen
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-16 Thread Gunnar Peterson
Secure software you're (not) soaking in it.


On 7/16/06 8:32 AM, mikeiscool [EMAIL PROTECTED] wrote:

 On 7/16/06, ljknews [EMAIL PROTECTED] wrote:
 At 3:27 PM -0400 7/15/06, Goertzel Karen wrote:
 Content-class: urn:content-classes:message
 Content-Type: multipart/alternative;
   boundary=_=_NextPart_001_01C6A844.D6A28B6B
 
 I've been struggling for a while to synthesise a definition of secure
 software that is short and sweet, yet accurate and comprehensive. Here's
 what I've come up with:
 
 Secure software is software that remains dependable despite efforts to
 compromise its dependability.
 
 Agree? Disagree?
 
 I disagree about that being bumper-sticker size, and I think we really
 need bumper stickers.
 
 a better bumper sticker would be something like:
 
 secure software is what i write. call me now to find out how!
 
 ...
 
 i don't see the point of a short phrase. it's obvious what secure
 software is. software that has no bugs and no design faults.
 
 -- mic
 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php


___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-16 Thread Julie J.C.H. Ryan
So, if software is dependably bad and can dependably be counted on to  
fail, it's secure?

Especially if it resists attempts to compromise such dependability?


On Jul 15, 2006, at 3:27 PM, Goertzel Karen wrote:

 I've been struggling for a while to synthesise a definition of  
 secure software that is short and sweet, yet accurate and  
 comprehensive. Here's what I've come up with:

 Secure software is software that remains dependable despite efforts  
 to compromise its dependability.

 Agree? Disagree?

 --
 Karen Mercedes Goertzel, CISSP
 Booz Allen Hamilton
 703-902-6981
 [EMAIL PROTECTED]

 ___
 Secure Coding mailing list (SC-L)
 SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/ 
 listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/ 
 charter.php

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bumper sticker definition of secure software

2006-07-16 Thread Crispin Cowan




Goertzel Karen wrote:

  
  
  "Bumper sticker" definition of secure software

  I've been struggling for a while to synthesise a
definition of secure software that is short and sweet, yet accurate and
comprehensive.

My favorite is by Ivan Arce, CTO of Core Software, coming out of a
discussion between him and I on a mailing list about 5 years ago.
Reliable software does what it is supposed to do. Secure
software does what it is supposed to do, and nothing else.

Crispin
-- 
Crispin Cowan, Ph.D.  http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
 Necessity is the mother of invention ... except for pure math



___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php