[SC-L] Interesting article on the adoption of Software Security

[Kenneth R. van Wyk]

There's an interesting article out on Net-Security.org (see the full article 
at http://www.net-security.org/article.php?id=697) that addresses why 
software development organizations adopt (or do not adopt) a Software 
Security development methodology.  Check it out -- it's a good read, IMHO.

Among other things, it says, "...effective secure development will only become 
more widespread when organisations receive better education. To achieve this 
security consultancies need to adopt an active campaign and the media need to 
provide coverage."

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com

Re: [SC-L] Interesting article on the adoption of Software Security

[Jeff Williams]

Integrating security activities into the software development lifecycle is
going to be a major theme at OWASP AppSec 2004 (June 19/20 in NYC).  The
talks will cover a broad range of topics that web application and web
service developers must address, including metrics, training, standards, and
best practices. Almost every talk includes a process angle.

You can find out more and check out the agenda at http://www.owasp.org.
There are still a few seats left.  I hope you can join us.

--Jeff

Jeff Williams
Aspect Security, Inc.
http://www.aspectsecurity.com

- Original Message - 
From: "Kenneth R. van Wyk" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 08, 2004 12:05 PM
Subject: [SC-L] Interesting article on the adoption of Software Security


> There's an interesting article out on Net-Security.org (see the full
article
> at http://www.net-security.org/article.php?id=697) that addresses why
> software development organizations adopt (or do not adopt) a Software
> Security development methodology.  Check it out -- it's a good read, IMHO.
>
> Among other things, it says, "...effective secure development will only
become
> more widespread when organisations receive better education. To achieve
this
> security consultancies need to adopt an active campaign and the media need
to
> provide coverage."
>
> Cheers,
>
> Ken van Wyk
> -- 
> KRvW Associates, LLC
> http://www.KRvW.com

Re: [SC-L] Interesting article on the adoption of Software Security

[Florian Weimer]

* Kenneth R. van Wyk:

> There's an interesting article out on Net-Security.org (see the full article 
> at http://www.net-security.org/article.php?id=697) that addresses why 
> software development organizations adopt (or do not adopt) a Software 
> Security development methodology.  Check it out -- it's a good read, IMHO.

| Although consuming between 5-15% of a project's overall budget,
| organisations have learnt that the savings yielded by phased
| security assessments far outweigh the costs of performing them.

I don't think this is correct.  The costs for fixing bugs is higher
later in the product lifecycle (and the article cites confirming
data), but these costs might never materialize.  Only a fraction of
all bugs are found, and the vendor doesn't even have to fix all those
which have actually been discovered.

I've never seen any hard evidence that investment into proactive
measures during development (or call it "increased software quality")
pays off in the end, at least in the area of applications which are
neither safety-critical nor regulated in some form or other.  Only
those companies that want you to pay dearly for their services publish
claim after claim that those services actually save you money.  My own
experience suggests that a strong brand is far more significant in
making purchasing decisions than defect rate, and a really good brand
can enable a vendor to push critical security fixes back years,
towards the next software development/deployment cycle, thus
minimizing the costs.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com,
jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com,
tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.

RE: [SC-L] Interesting article on the adoption of Software Security

[John Steven]

Re: [SC-L] Interesting article on the adoption of Software Security

[Damir Rajnovic]

On Wed, Jun 09, 2004 at 10:37:45AM +0200, Florian Weimer wrote:
> I don't think this is correct.  The costs for fixing bugs is higher
> later in the product lifecycle (and the article cites confirming
> data), but these costs might never materialize.  Only a fraction of
> all bugs are found, and the vendor doesn't even have to fix all those
> which have actually been discovered.

While this is true that only some of the bugs are fixed that fixing can
have unexpectedly high price tag attached. No matter how do you look
at this it _is_ cheaper to fix bugs as soon as possible in the process
(or not introduce them at the first place).

> I've never seen any hard evidence that investment into proactive
> measures during development (or call it "increased software quality")
> pays off in the end, at least in the area of applications which are

Personally, I do not see how this can be easily measured. The only way
we can do that is to say that we used to have so many bugs previoulsy
and fixing them cost that many. Then say that now we have so many
fewer bugs and that brought saving of whatever amount. But all of that
is just a guesswork and not the hard data. The conclusion is that you
can accurately only measure how much fixing cost (and only the technical
part, without trying to estimate lost opportunites and lost customer
confidence) but can not measure the absence of bugs.

The other interesting bit is that, at least at my place, we are seeing
fewer "simple" bugs but more of "complex" one. Not necessarily "complex"
in a sense of how hard is to fix them (but, occasionally, that too) but
that they tend to be more fundamental and far reaching then "simple"
ones. The consequence of it is that, while you may have fewer bugs, the
cost of fixing them stays the same or is even greater then fixing many
"simple" bugs.

Gaus

==
Damir Rajnovic <[EMAIL PROTECTED]>, PSIRT Incident Manager, Cisco Systems
  Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==
There are no insolvable problems. 
The question is can you accept the solution? 

Re: [SC-L] Interesting article on the adoption of Software Security

[Crispin Cowan]

Damir Rajnovic wrote:
While this is true that only some of the bugs are fixed that fixing can
have unexpectedly high price tag attached. No matter how do you look
at this it _is_ cheaper to fix bugs as soon as possible in the process
(or not introduce them at the first place).
 

This is true in the isolation of looking at the cost of fixing any one 
individual bug, but it is not true in general. Fixing one bug early in 
the process is cheap and easy. Fixing the *last* bug in a system is 
astronomically expensive, because the cost of *finding* bugs rises 
exponentially as you further and further refine it. Worse, you 
eventually reach a point of equilibrium where your chances of inserting 
a new bug in the course of fixing a known bug are about even, and it 
becomes almost impossible to reduce the bug count further.

Personally, I do not see how this can be easily measured.
This entire area is rife with mushy psychological issues involving 
huan's ability to process information correctly. As a result, nearly all 
of the absolute statements are wrong, and they function only within 
certain ranges, .e.g. fixing bugs early in development is cheaper than 
patching in the field, but only within the bounds of digging only so 
hard for bugs.

But even this statement is self-limiting. The above claim is not true 
(or at least less true) for safety-critical systems like fly-by-wire 
systems and nuclear reactor controllers, where the cost of failure due 
to a bug is so high that it is worth paying the extra $$$ to find the 
residual bugs in the development phase.

My reaction to the feuding over whether it is better to shore up C/C++ 
or to use newer safer languages like Java and C#: each has their place.

   * There are millions of lines of existing C/C++ code running the
 world. Holding your breath until they are all replaced with type
 safe code is not going to be effective, and therefore there is
 strong motive to deploy tools (e.g. StackGuard, RATS, etc.) to
 improve the safety of this code.
   * New code should be written in type safe languages unless there is
 a very strong reason to do otherwise.
Crispin
--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix  http://immunix.com

Re: [SC-L] Interesting article on the adoption of Software Security

[Dana Epp]

Ok, lets turn the tables a bit here. We talked about this a bit back 
last December when I said that you need to use the right tool for the 
right job, and to quit beating on C.

For those of us who write kernel mode / ring0 code, what language are 
you suggesting we write in? Name a good typesafe language that you have 
PRACTICALLY seen to write kernel mode code in. Especially on Windows and 
the Linux platform. I am not trying to fuel the argument over which 
language is better, it comes down to the right tool for the right job. I 
know back in December ljknews suggested PL/I and Ada, but who has 
actually seen production code in either Windows or Linux using it?

Lets face it. You aren't going to normally see Java or C# in kernel code 
(yes I am aware of JavaOS and some guys at Microsoft wanting to write 
everything in their kernel via managed code) but its just not going to 
happen in practice. C and ASM is the right tool in this area of code.

I said this back in December and think its worth repeating. What is the 
C language downfall is also its best strength. It is a double edged 
sword that really SHOULD be mastered by those who need it, but by many 
is treated like a child's $5 plastic toy... wielded by the inexperienced 
who don't know any better. The reality is instead of avoiding it, we 
should include the proper teachings to use it safely, and correctly. I 
think that if we try to sidestep the issue, we will end up using the 
wrong tool at the wrong time. We shouldn't fear using languages like C 
and C++, we just need to know its place, know its fallibilities and deal 
with it.

Cripin is right; new code SHOULD be written in a type safe language 
unless there is a very strong reason to do otherwise. The reality is 
that many developers don't know when that right time is. And resulting 
is poor choice in tools, languages and structure. I'd love for someone 
to show me... no... convince me, of a typesafe language that can be used 
in such a place. I have yet to see it for production code, used on a 
regular basis.

Now whats interesting is that some people are starting to get this. If 
you look at some of the latest DDK builds coming out of Microsoft you 
now see advancements in tools to handle this. Tools like prefast can do 
a lot to analyze code, and the new Static Driver Verifier goes to the 
next level when tracing code execution paths and checking for faults in 
drivers traditionally written in C. They further extend that with safer 
string functions () and deeper inspection in code as well 
as lots of training to bring people up to skill in secure programming 
through some of their MSDN webcasts. Now, I am NOT saying Microsoft is 
the company I would look to for a model in this area, but I am seeing 
the effort there. The trick is actually educating the developers to use 
the tools, and use them properly. (RATS and StackGuard were some good 
ones Crispin pointed out).

Its the right tool for the right job. And although you can pound a 
square peg through a round hole if you beat it hard enough... it doesn't 
mean its the right thing to do. Nor is right to assume you can use 
typesafe languages as the panacea for secure coding.

--
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]

Re: [SC-L] Interesting article on the adoption of Software Security

[ljknews]

At 2:00 PM -0700 6/10/04, Dana Epp wrote:
>Ok, lets turn the tables a bit here. We talked about this a bit back last December 
>when I said that you need to use the right tool for the right job, and to quit 
>beating on C.
>
>For those of us who write kernel mode / ring0 code, what language are you suggesting 
>we write in? Name a good typesafe language that you have PRACTICALLY seen to write 
>kernel mode code in. Especially on Windows and the Linux platform. I am not trying to 
>fuel the argument over which language is better, it comes down to the right tool for 
>the right job. I know back in December ljknews suggested PL/I and Ada, but who has 
>actually seen production code in either Windows or Linux using it?

Restricting your domain of inquiry to C-centric operating systems
is not exactly a reasonable set of ground rules.  This is, after all,
not a mailing list restricted to Windows and Linux.  Even this _topic_
is not restricted to Windows and Linux. As an advocate of strongly typed languages, I 
do not use either (causality speculation is left to the
reader).

If you want to look for worked examples of operating systems in strongly
typed languages, consider Multics, which was responsible for popularizing
ring structures for operating systems.  I used Dockmaster, but never did
any programming on Multics.

(In case anyone is unaware, Multics was written in PL/I.)

RE: [SC-L] Interesting article on the adoption of Software Security

[Michael S Hines]

Likewise for the IBM Mainframe operating systems MVS,OS/390,z/OS - much of
which is written in (I believe) PL/M - a dialect much like PL/1.

Many of our Operating Systems seem to have evolved out of the old DEC RSTS
system.  For example, CP/M had a PIP command.  Later renamed to COPY in DOS.


UNIX had a hierarchical file structure.  DOS inherited this feature early
on.  

When you've been around for a while, you start to see the same features
converge..  UNIX had quotas, we got Quotas with Win XP Server (well earlier,
when you include the third party ISVs - as an add on).  IBM had Language
Environment (LE) before .NET come along.  

It all sort of runs together over time - it seems.

Mike Hines
---
Michael S Hines
[EMAIL PROTECTED] 

Re: [SC-L] Interesting article on the adoption of Software Security

[Crispin Cowan]

ljknews wrote:
At 2:00 PM -0700 6/10/04, Dana Epp wrote:
 

Ok, lets turn the tables a bit here. We talked about this a bit back last December 
when I said that you need to use the right tool for the right job, and to quit beating 
on C.
For those of us who write kernel mode / ring0 code, what language are you suggesting we write in? Name a good typesafe language that you have PRACTICALLY seen to write kernel mode code in. Especially on Windows and the Linux platform. I am not trying to fuel the argument over which language is better, it comes down to the right tool for the right job. I know back in December ljknews suggested PL/I and Ada, but who has actually seen production code in either Windows or Linux using it?
   

Restricting your domain of inquiry to C-centric operating systems
is not exactly a reasonable set of ground rules.  This is, after all,
not a mailing list restricted to Windows and Linux. 

I strongly disagree. While it is not reasonable to limit this *list* to 
C-oriented operating systems, it is a perfectly reasonable question for 
a developer for Windows and Linux kernel enhancements to ask what 
programming language or programming techniques they should use to 
improve the security of their development efforts. Windows and Linux 
collectively representing some huge plurality of all deployed computer 
systems, it is a very practical question.

Even this _topic_
is not restricted to Windows and Linux. As an advocate of strongly typed languages, I do not use either 

That's nice, but it does not help the person who has to enhance legacy C 
code, which is a very real problem.

Crispin
--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix  http://immunix.com

Re: [SC-L] Interesting article on the adoption of Software Security

[der Mouse]

> For those of us who write kernel mode / ring0 code, what language are
> you suggesting we write in?  Name a good typesafe language that you
> have PRACTICALLY seen to write kernel mode code in.

Lisp.  I used Lisp Machines back when I worked in academia, and almost
everything was in Lisp, including most of what would in a more
conventional OS be called the kernel.

Of course, the Lisp dialect they used was not, strictly, typesafe,
since it had subprimitives that allowed you to assemble arbitrary
lispvals out of nothing.  (In fact, I submit that a language that does
not have some analog thereof _cannot_ be suitable for writing the
lowest-level kernel code, though it may be fine for the more
disciplined parts of the kernel.  Vide infra.)

> Especially on Windows and the Linux platform.

If you're restricting yourself to OS Foo, then you will have a very
hard time finding a language suitable for OS hacking except for the
language(s) that Foo is written in.

For example, you are unlikely to have an easy time of doing Linux
kernel code in any language but gcc.

> What is the C language downfall is also its best strength.

Yes.  It's a little like a Formula 1 racecar: touchy, unforgiving...and
a good deal more powerful than your average car.

Of course, you don't go shopping for groceries in a F1 racecar; C is
not always the right answer.  But simply because it does not force code
to be typesafe does not automatically make it the wrong answer, either.
(For example, I have trouble imagining how you could build the VM
subsystem in a language that did enforce type safety.)

The problem is not C.
The problem is using C when it's not the right language.

Note also that "the right language" varies not only with the problem,
but with other things too, such as who's going to be writing the code.
(As a simple example, C is a right language for more problems for me,
who's been using it for going on twenty years now, than it is for
someone who got a little of it in half of a course last semsester but
really knows Visual BASIC inside and out.)

/~\ 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

RE: [SC-L] Interesting article on the adoption of Software Security

[ljknews]

At 9:16 AM -0500 6/11/04, Michael S Hines wrote:

> IBM had Language Environment (LE) before .NET come along.  

What is Language Environment (for either of those) ?

Re: [SC-L] Interesting article on the adoption of Software Security

[Crispin Cowan]

Michael S Hines wrote:
Likewise for the IBM Mainframe operating systems MVS,OS/390,z/OS - much of
which is written in (I believe) PL/M - a dialect much like PL/1.
 

If PL/M is the language I am remembering from an embedded systems class 
back in the 1980s, then it is not at all like PL/1. Rather, it is a 
completely type-unsafe language. I would say "similar to C", in that it 
has most of the same pitfalls. However, where ever C made an arbitrary 
decision (either way is just as good) PL/M went the opposite direction 
from C, making it very annoying for a C programmer to use.

Many of our Operating Systems seem to have evolved out of the old DEC RSTS
system.  For example, CP/M had a PIP command.  Later renamed to COPY in DOS.
 

True.
When you've been around for a while, you start to see the same features
converge..  UNIX had quotas, we got Quotas with Win XP Server (well earlier,
when you include the third party ISVs - as an add on).  IBM had Language
Environment (LE) before .NET come along.  
 

I think .Net borrows most heavily from Java. Java in turn borrows from 
everyone. The "managed code" thing in particular leads back to the 
Pascal P-code interpreter; a kludge to make the Pascal compiler easier 
to implement and port. The innovation in Java was to take this ugly 
kludge and market it as a feature :)

Crispin
--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix  http://immunix.com

Re: [SC-L] Interesting article on the adoption of Software Security

[Andreas Saurwein]

Crispin Cowan wrote:
However, where ever C made an arbitrary decision (either way is just as 
good) PL/M went the opposite direction from C, making it very annoying for 
a C programmer to use.
Does that mean it did not make any decision at all? What was the outcome?
Michael S Hines wrote:
When you've been around for a while, you start to see the same features
converge..  UNIX had quotas, we got Quotas with Win XP Server (well earlier,
when you include the third party ISVs - as an add on).  IBM had Language
Environment (LE) before .NET come along.
Crispin Cowan wrote:
I think .Net borrows most heavily from Java. Java in turn borrows from 
everyone. The "managed code" thing in particular leads back to the Pascal 
P-code interpreter; a kludge to make the Pascal compiler easier to 
implement and port. The innovation in Java was to take this ugly kludge 
and market it as a feature :)
I'm not sure that it can be blamed on Pascal. Microsoft was shipping Excel 
for the Mac in the early 80's as P-Code application and has been selling 
P-Code generating compilers since about the same time. Ever since, MS was 
strong on P-Code generating compilers.

Michael, let me please correct two more things in your comment:
1) there is no such thing as a Windows XP server (probably you refer to 
Windows 2003 Server)
2) Quotas have been native to Windows 2000 already (lets not discuss quota 
management now...)

cheers
Andreas 

RE: [SC-L] Interesting article on the adoption of Software Security

[Wall, Kevin]

Dana Epp wrote...

[...snip...]
> For those of us who write kernel mode / ring0 code, what language are 
> you suggesting we write in? Name a good typesafe language that you have 
> PRACTICALLY seen to write kernel mode code in. Especially on Windows and
> the Linux platform. I am not trying to fuel the argument over which 
> language is better, it comes down to the right tool for the right job. I
> know back in December ljknews suggested PL/I and Ada, but who has 
> actually seen production code in either Windows or Linux using it?

I suppose it's _possible_ that one might be able to sneak in a bit of
carefully constructed C++ in one of these kernels, but you'd probably
have to be very careful about what you used (e.g., probably most of
STL is out) and in the end, you'd probably have to use

extern "C" {
  ...
}

wrappers around most of your stuff so it could interface with the
rest of the kernel.

I thought of doing something like this back in 1990 when working on
device drivers with the Unix System V kernel at Bell Labs, but the
potential problems (several having to do with DTORs IIRC and the binding
issues) seemed to outweigh any potential gain. I thought of also using
C++ as "a better (more strongly typed) C", but that too didn't seem
worth it.

Of course, there are some kernels that were implemented in C++; Clouds
comes to mind.

> Lets face it. You aren't going to normally see Java or C# in kernel code
> (yes I am aware of JavaOS and some guys at Microsoft wanting to write 
> everything in their kernel via managed code) but its just not going to 
> happen in practice. C and ASM is the right tool in this area of code.

I'd pretty much agree with this. You seldom even see Java or C# used in
real-time systems (and let's face it, the kernel itself is pretty much
real-time; don't want to be missing an interrupt while doing GC).
Perhaps once the Real-time Specification for Java is approved and
implemented by Sun, this will change, but I don't think that we'll
be seeing many new OSes adopt Java or C# for their kernel code.
(However, I think this also has to do in part with the fact that most
OS/kernel developers are not experts in OO...just my opinion.)

[...snip...]
> Cripin is right; new code SHOULD be written in a type safe language 
> unless there is a very strong reason to do otherwise. The reality is 
> that many developers don't know when that right time is. And resulting 
> is poor choice in tools, languages and structure.

I think, in a large part, that's because your average developer knows
only one or maybe two programming languages. And if they know more,
they only know languages from a single paradigm (e.g., OO, logic programming,
functional programming, procedural, etc.).  Because of this, the view is
"when all you have is a hammer, everything looks like a nail".

> I'd love for someone to show me... no... convince me, of a
> typesafe language that can be used in such a place.
 

Not sure I get your drift here. Did you mean "in commercial systems"
or in OS kernels or something else? (Cut me some slack; I've only
had 2 cups of coffee so far. ;-)

> I have yet to see it for production code, used on a regular basis.

Here at Qwest, we've been pretty much exclusively using nothing else
besides Java and C# since the last 6 years. (Java for about 6+ years
and C# for the past 2 years.)

So buffer overflows are pretty much things of the past, but developers
still don't validate most of their input data so there's still plenty
of XSS and SQL injection problems left. (IMO, these are just another
example of failure to do proper data validation, as are buffer overflows.)

[...snip...]
> ... Nor is right to assume you can use 
> typesafe languages as the panacea for secure coding.

To be sure, about 50% of the security holes that I still see are
the results of dumb design decisions (e.g., no authorization checks
whatsoever, placing sensitive data in persistent cookies, etc.).
Keeps my team plenty busy. ;-)

OTOH, I'm sure we'd be a lot worse off if developers here were still
allowed to use C or C++ to write new code in.

Cheers,
-kevin
---
Kevin W. Wall   Qwest Information Technology, Inc.
[EMAIL PROTECTED]   Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former Whitehouse cybersecurity advisor, Richard Clarke,
at eWeek Security Summit 

Re: [SC-L] Interesting article on the adoption of Software Security

[Crispin Cowan]

Andreas Saurwein wrote:
Crispin Cowan wrote:
However, where ever C made an arbitrary decision (either way is just 
as good) PL/M went the opposite direction from C, making it very 
annoying for a C programmer to use.
Does that mean it did not make any decision at all? What was the outcome?
No, just trivial decisions on syntax. It made my fingers hurt to use it, 
because I had to retrain a lot of habits. Unfortunately I no longer 
remember the specifics.

When you've been around for a while, you start to see the same features
converge..  UNIX had quotas, we got Quotas with Win XP Server (well 
earlier,
when you include the third party ISVs - as an add on).  IBM had 
Language
Environment (LE) before .NET come along.
Crispin Cowan wrote:
I think .Net borrows most heavily from Java. Java in turn borrows 
from everyone. The "managed code" thing in particular leads back to 
the Pascal P-code interpreter; a kludge to make the Pascal compiler 
easier to implement and port. The innovation in Java was to take this 
ugly kludge and market it as a feature :)
Michael S Hines wrote:
I'm not sure that it can be blamed on Pascal. Microsoft was shipping 
Excel for the Mac in the early 80's as P-Code application and has been 
selling P-Code generating compilers since about the same time. Ever 
since, MS was strong on P-Code generating compilers.
The UCSD Pascal P-Code system was released in 1978 
. 
MS Excel was released in 1984 
. And if anything, 
the above claim that MS has been using P-code since the early days of 
Excel only supports the claim that Pascal P-Code is the origin of the 
idea at Microsoft.

Crispin
--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix  http://immunix.com