[SC-L] security half-life and critical mass
Mark Graff wrote: > I have therefore often wondered if we should be talking, not about how > "secure" a system is, in a static sense, but rather what its security > half-life is. Interesting point! > This reasoning leads me to the > thought that Mac OS X, for example, is "more secure" than Windows XP for > reasons having nothing directly to do with design or implementation, but > rather pertaining to its very ubiquity. XP, in this sense, is the center of > the bullseye. This one however has been raised many times before. Yes, if MacOS (or Linux or BSD or OS/2 or whatever) had a much larger market share, there would be many more attacks developed against it than now. However, from all I've read (not having actually TRIED to attack it myself), it is indeed much more securely designed, implemented, and typically deployed, installed, and maintained, than Windows. So, assuming equal market share, I predict that you'd have several times the viruses, worms, rootkits, etc. directed against Windows, simply because there are several times as many chinks in its armor, and, just as now, gazillions of times as many Windows machines actually broken into or otherwise damaged due to bad security, as Mac. > Gee, maybe software systems emanate a modicum of "unsecurity gravity", so > that if you get a great many of them together (that is, if millions and > millions of people buy the product), security plummets, and declines as the > square of the distance to True Dead Center of the day's commonplace > platform. Or, to put it another way, this is why XP sucks. It's one factor. If the market share figures were reversed, there would probably not be as many attacks written for it, and certainly there would be fewer worm-infected machines trying to attack other XP boxen. But it's far from the only reason. > - Original Message - > From: <[EMAIL PROTECTED]> > To: > Sent: Friday, July 21, 2006 5:05 AM > Subject: SC-L Digest, Vol 2, Issue 124 Please trim your quoted matter to just what's necessary to give us a clue what you're talking about. Google nettiquette. -Dave ___ 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
[SC-L] Cost of provably-correct code (was: bumper sticker slogan for secure software)
Crispin Cowan wrote on 21 July 2006 18:45: >> Yes, you can have provably correct code. Cost is approximately $20,000 per line of code. That is what the "procedures" required for correct code cost. Oh, and they are kind of super-linear, so one program of 200 lines costs more than 2 programs of 100 lines. << To arrive at that cost, I can only assume that you are referring to a process in which all the proofs are done by hand, as was attempted for a few projects in the 1980s. We current achieve automatic proof rates of 98% to 100% (using PD), and I hear that Praxis also achieves automatic proof rates well over 90% (using Spark) these days. This has brought down the cost of producing provable code enormously. You are perhaps also including the cost of verifying the object code against the source code. Although this is sometimes a requirement in the safety-critical software world, I think it unlikely to be necessary for all but a very few secure applications, assuming a mature compiler is used. >> Indeed, consider SQL injection attacks. They didn't exist 5 years ago, because no one had thought of them. Same with XSS bugs. Same with printf format string attacks. All of them are examples of processing user input without validation, but they are all really big classes of such, and they were discovered to occur in very large numbers in common code. What Dana is trying to tell you is that some time in the next year or so, someone is going to discover yet another of these major vulnerability classes that no one has thought of before. At that point, a lot of code that was thought to be reasonably secure suddenly is vulnerable. << I agree, a new class of vulnerability may well be discovered. However, if the code was specified and developed so as to be provably correct, then it is highly likely that immunity to a new class of attack can be expressed by adding additional formal requirements, allowing an immediate evaluation of where in the design and implementation the vulnerabilities (if any) lie. David Crocker, Escher Technologies Ltd. Consultancy, contracting and tools for dependable software development www.eschertech.com ___ 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 slogan for secure software
mikeiscool wrote: > On 7/21/06, Dana Epp <[EMAIL PROTECTED]> wrote: > >>> yeah. >>> but none of this changes the fact that it IS possible to write completely >>> secure code. >>> >> 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 difficult to have code be 100% correct if an application >> has any level of real use or complexity. There will be security defects. >> > Why? Why accept this as a fact? It is not a fact. If you put > procedures in place and appropriately review and test you can be > confident. > Sorry, but it is a fact. Yes, you can have provably correct code. Cost is approximately $20,000 per line of code. That is what the "procedures" required for correct code cost. Oh, and they are kind of super-linear, so one program of 200 lines costs more than 2 programs of 100 lines. >> More importantly, threats are constantly evolving and what you may >> consider completely secure today may not be tomorrow when a new attack >> vector is recognized that may attack your software. >> > This isn't as true and as wide spread as you make it sound. Consider, > for example, "SQL Injection". Assuming I do not upgrade my database, > and do not change my code and server (i.e. do not change my > environment at all), then if I have prevented this attack initially > nothing new will come up to suddenly make it work. > Indeed, consider SQL injection attacks. They didn't exist 5 years ago, because no one had thought of them. Same with XSS bugs. Same with printf format string attacks. All of them are examples of processing user input without validation, but they are all really big classes of such, and they were discovered to occur in very large numbers in common code. What Dana is trying to tell you is that some time in the next year or so, someone is going to discover yet another of these major vulnerability classes that no one has thought of before. At that point, a lot of code that was thought to be reasonably secure suddenly is vulnerable. >> And unless you wrote >> every single line of code yourself without calling out to ANY libraries, >> you cannot rely on the security of other libraries or components that >> may NOT have the same engineering discipline that you may have on your >> own code base. >> > Not true; you can call other libraries happily and with confidence if > you handle the case of them going all kinds of wrong. > This also is false. Consider the JPG bug that badly 0wned Microsoft desktops a while back. It was a bug in an image processing library. You try to view an image by processing it with the library, and the result is that the attacker can execute arbitrary code in your process. That is pretty difficult to defensively program against. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unaticipated problem Hacker: one who is adroit at pounding round pegs into square holes ___ 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 slogan for secure software
There's another point to consider, when talking about whether True Security is Possible. And I have to say I've never been happy with the forms I've found so far to express it... Security, in many cases, decays. It's like what we used to call, in the Old Days, "bit rot". Software that has "worked" "perfectly well" for years (that is, failures and mistakes have fallen under the threshold of detection) suddenly stop "working". Often, it's because some element of the environment in which the system runs has changed around it. It could be a library that the program uses, for instance. I suppose it could be a change in the way the software is used, or applied. So while most software decays in some way while it ages, I seem to observe that the security aspect of a program decays faster than the rest of it. (This has some analogies in the "real" world. Some parts of a car, for example, wear out faster than the rest. Tires and Brake pads. It's an interesting feature of good design, of course, to isolate the effects of wear and tear into parts intended to be disposable. But I digress.) I have therefore often wondered if we should be talking, not about how "secure" a system is, in a static sense, but rather what its security half-life is. This is the point of my hoary thought experiment (sorry if you've heard this one) in which we prepare a desktop with the latest and greatest in the way of anti-virus stuff, firewalls, OS patches, and so forth, then spin it down, shrink-wrap it, and put it in a closet. If we take it out a year later and spin it up, that system will be less sure--more likely to successfully be compromised--than it was when it was spun down. How fast security decays will vary, depending mostly on which OS and app software it runs and how corrosive, if you will, that part of the overall operating landscape (the Internet, say) is. This reasoning leads me to the thought that Mac OS X, for example, is "more secure" than Windows XP for reasons having nothing directly to do with design or implementation, but rather pertaining to its very ubiquity. XP, in this sense, is the center of the bullseye. Gee, maybe software systems emanate a modicum of "unsecurity gravity", so that if you get a great many of them together (that is, if millions and millions of people buy the product), security plummets, and declines as the square of the distance to True Dead Center of the day's commonplace platform. Or, to put it another way, this is why XP sucks. Well, I said I've never been happy with the way I've expressed this. -mg- - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Friday, July 21, 2006 5:05 AM Subject: SC-L Digest, Vol 2, Issue 124 > Send SC-L mailing list submissions to > sc-l@securecoding.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://krvw.com/mailman/listinfo/sc-l > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SC-L digest..." > > > Today's Topics: > > 1. Re: bumper sticker slogan for secure software (Pascal Meunier) > 2. Re: bumper sticker slogan for secure software > ([EMAIL PROTECTED]) > 3. Re: bumper sticker slogan for secure software (Florian Weimer) > 4. Re: bumper sticker slogan for secure software (Pascal Meunier) > 5. Re: bumper sticker slogan for secure software (ljknews) > 6. Re: bumper sticker slogan for secure software (Pascal Meunier) > 7. Re: bumper sticker slogan for secure software (ljknews) > 8. Re: bumper sticker slogan for secure software (Dana Epp) > 9. Re: bumper sticker slogan for secure software (John Wilander) > > > -- > > Message: 1 > Date: Thu, 20 Jul 2006 15:11:06 -0400 > From: Pascal Meunier <[EMAIL PROTECTED]> > Subject: Re: [SC-L] bumper sticker slogan for secure software > To: Gary McGraw <[EMAIL PROTECTED]>, Florian Weimer <[EMAIL PROTECTED]>, > der Mouse <[EMAIL PROTECTED]> > Cc: SC-L@securecoding.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="ISO-8859-1" > > > > 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 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. For design/requirements > bugs, > I'm reading: > > Why Are Formal Methods Not Used More Widely? > John C. Knight Colleen L. DeJong Matthew S. Gibble Lu?s G. Nakano > Department of Computer Science > University of Virginia > C
[SC-L] Administrivia: Bumper Stickers
Greetings SC-L, It's been a busy couple of days here on SC-L. The bumper sticker thread, in particular, has obviously generated a *lot* of (useful and interesting) discussion. While I'm reluctant to stop legitimate and open debate of opinions, I think that it's fair to say that this thread has pretty much run its course. As such, I'm going to be increasingly diligent in rejecting submissions to it that don't carry the debate further. I'd like to ask for everyone's support in helping this thread die its natural death and move on to other subjects. So, to those that want to continue the thread, be prepared to prove to me with each message that your message(s) deserves to be approved for distribution to the list, please. Cheers, Ken Kenneth Van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com ___ 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 slogan for secure software
I've actually been using a secure software slogan for a few years, both in teaching and in pitching business. It's taken from Howard and LeBlanc's book "Writing Secure Code": - Security features are not secure features - The statement mesmerizes people and aguably needs a "necessarily" to be more precise. But it's short and does the trick for me---it separates adding security functions from trying to secure all functions in the system (during all phases). Regards, John John Wilander, PhD Student Computer and Information Sc. Linkoping University, Sweden http://www.ida.liu.se/~johwi ___ 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 slogan for secure software
On 7/21/06, Dana Epp <[EMAIL PROTECTED]> wrote: > > 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 difficult to have code be 100% correct if an application > has any level of real use or complexity. There will be security defects. Why? Why accept this as a fact? It is not a fact. If you put procedures in place and appropriately review and test you can be confident. > The weakest link here is the human factor, and people make mistakes. Yes they do. So help them to stop it by teaching and testing and reviewing. > More importantly, threats are constantly evolving and what you may > consider completely secure today may not be tomorrow when a new attack > vector is recognized that may attack your software. This isn't as true and as wide spread as you make it sound. Consider, for example, "SQL Injection". Assuming I do not upgrade my database, and do not change my code and server (i.e. do not change my environment at all), then if I have prevented this attack initially nothing new will come up to suddenly make it work. If the environment IS changed, however, then of course it's expected that the program should be reviewed and checked again. > And unless you wrote > every single line of code yourself without calling out to ANY libraries, > you cannot rely on the security of other libraries or components that > may NOT have the same engineering discipline that you may have on your > own code base. Not true; you can call other libraries happily and with confidence if you handle the case of them going all kinds of wrong. > 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 there. If we build systems to > maintain confidentiality, integrity and availability, we have the > ability to fail gracefully in a manner to recover from unknown or > changing problems in our software without being detrimental to the user, > or their data. > > I don't think we should ever stop striving to reach secure coding > nirvana. But I also understand that in the real world we are still in > our infancy when it comes to secure software as a discipline, and we > still have much to learn before we will reach it. Yes, Much to learn. Like the fact that it _is_ reachable if you believe you can reach it. And, you know, study yoga and live in a cliff for a few years. > Regards, > Dana Epp > [Microsoft Security MVP] > http://silverstr.ufies.org/blog/ -- 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 slogan for secure software
> What is important is that some magic formal tool could say that some > code in language "A", where bug of type "k" is possible, is not > equivalent to the version in language "B", where type "k" bugs are > impossible, ergo you have found a type "k" bug (in the absence of any > other bug in that section of code...). Well, no. You know that a bug exists. It could be in one version (you don't know which one), or it could be in the verifier. If you assume that the verifier is bug-free, and you assume that the language-A version is semantically correct, then you know that a bug exists in the language-B version. It might be of type k or it might be of some other type (possibly a type that can exist in language A, possibly not). And in any case, you have not found it; you have only demonstrated its existence. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ 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 slogan for secure software
>> You might want to read Thompson's classic "reflections on trusting >> trust". www.acm.org/classics/sep95 > While that is always a good read, I'm not so sure it's that relevant > anymore. There is a LOT of binary analysis going on these days. Yes - but you're trusting your binary analysis tools to be intact. You're trusting the OS to give you honest copies of what's on disk. You're trusting lots of things which could be subverted - you could be talking to a complete funkspiel, in theory. At some point you have to say "the chance of the system being subverted here is low enough I'm going to ignore it". For example, when I buy transistors from the electronics shop, I don't worry about the possibility that they have enough smarts inside them to act in weird ways when used in certain applications. As a theoretical example of the kind of thing I mean, consider a transistor that, when used as a switch in a serial-line level-shifter, replaces the incoming data with other data. I choose to trust that the stuff inside the package is sufficiently close to what I think it is to not introduce any insecurities relevant to my threat model. But if my threat model included an adversary sufficiently resourceful and subtle to subvert the electronic-part distribution chain upstream of me, and the price of getting subverted were high enough, I might want to set up a small smelter/forge/whatever to make my own transistors. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ 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
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 slogan for secure software
Actually, Brian Shea got the points for emailing me that he knew it was
the system error "Access Denied".
An extra 10 points goes to Andrew van der Stock for his explaination
that:
"apparently the term originates from radio, where 5x5 means good
reception and good signal strength (in that order). So
0x5
means
- no reception ("0")
- good signal strength ("5")
ie, we're doing ok at getting our message out, but people aren't
listening yet. "
That cracked me up. So fitting for this forum.
Regards,
Dana Epp
[Microsoft Security MVP]
http://silverstr.ufies.org/blog/
-Original Message-
From: mikeiscool [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 20, 2006 3:25 PM
To: Wall, Kevin
Cc: Dana Epp; SC-L@securecoding.org
Subject: Re: [SC-L] bumper sticker slogan for secure software
> BTW, does anyone besides me think that it's time to put this thread to
> rest?
I do.
But i'm still waiting for my points from dana ...
> -kevin
-- 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
