[SC-L] SecAppDev is just over a month away

[Kenneth R. van Wyk]

Hey SC-L folks,

SecAppDev 2014 is just over a month from now. I hope that at least a few of you 
will be at this year's event.

SecAppDev is a non-profit software security training event in Leuven, Belgium. 
It's a week-long event featuring a spectrum of training classes and hands-on 
modules taught by some of the industry's best and brightest (oh, and me too ;-).

Details are available at http://secappdev.org, as usual. Many of the modules 
from prior years are available for you to watch there as well.

New this year for me, I'll be delivering a module on hardening iOS apps against 
various attacks -- forensics and reverse engineering. Should be fun, and I hope 
there'll be plenty of interesting discussions during and after the session as 
well.

Cheers,

Ken

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

Follow us on Twitter at: @KRvW or @KRvW_Associates



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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] SecAppDev hits the road

[Kenneth R. van Wyk]

Greetings SC-L subscribers,

I suspect many of you have heard of SecAppDev (http://secappdev.org) over the 
years. It's a non-profit training event that has hitherto been held in Leuven, 
Belgium for 1 week each Feb/Mar. Well, we're excited to say that this year 
we've added a second event: SecAppDev Dublin!

Yes, SecAppDev will be hitting the road for its first foray outside of Belgium. 
For one week in July (15th-19th), we'll be making Dublin, Ireland our home. 
Just like the events in Belgium, we've lined up a great curriculum and faculty, 
to give each delegate a look at myriad aspects of developing secure 
applications. It's a pretty intense week-long immersion into the topics, for 
sure.

Registration is now open. The course is organized by secappdev.org, a 
non-profit organization that aims to broaden security
awareness in the development community and advance secure software engineering 
practices. The course is a joint initiative with Dublin City University, 
Trinity College Dublin, KU Leuven and Solvay Brussels School of Economics and
Management.

SecAppDev Dublin is the first edition of our widely acclaimed courses to be run 
in Ireland. Our previous 9 courses took place in Belgium and were attended by 
an international audience from a broad range of industries including financial 
services, telecom, consumer electronics and media. We pride ourselves on our 
world-class faculty, which, for SecAppDev Dublin, includes

+ Prof. dr. ir. Bart Preneel who heads COSIC, the renowned Leuven crypto lab.
+ Ken van Wyk, co-founder of the US CERT Coordination Center and widely  
acclaimed author and lecturer.
+ Prof. dr. Dan Wallach, head of Rice University's computer security lab.
+ Prof. dr. Mike Scott, previously the head of DCU's School of Computing, now  
Chief Cryptographer at Certivox.

When we ran our first annual course in 2005, emphasis was on awareness and 
security basics, but as the field matured and a thriving security training 
market developed, we felt it was not appropriate to compete as a non-profit 
organization. Our focus has hence shifted to providing a platform for 
leading-edge and experimental material from thought leaders in academia and 
industry. We look toward academics to provide research results that are ready 
to break into the mainstream and attract people with an industrial background 
to try out new content and formats.

The course takes place from July 15th to 19th at the Science Gallery, Trinity 
College, Dublin.

For more information visit the web site: http://secappdev.org.

Seating is limited, so do not delay registering to avoid disappointment. 
Registration is on a first-come, first-served basis.  A 25% discount is 
available for Early Bird registration until June 15th. Alumni, public servants, 
and independents receive a 50% discount.  I hope that we will be able to 
welcome you or your colleagues to our course.

Cheers,

Ken

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

Follow us on Twitter at: @KRvW or @KRvW_Associates





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] ANNOUNCING: #MobAppSecTri Scholarship Program

[Kenneth R. van Wyk]

Hey SC-Lers,

Gunnar Peterson (@OneRaindrop) and I (@KRvW) are once again giving away to a 
few deserving Mobile App Developers a small number of FREE tickets to our next 
Mobile App Sec Triathlon. If you know any deserving students / interns 
(especially in the greater New York City region), point them in our direction 
for a chance to get a free seat.

See 
http://mobappsectriathlon.blogspot.com/2013/03/announcing-mobappsectri-scholarship.html
 for details.

Cheers,

Ken

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

Follow us on Twitter at: @KRvW or @KRvW_Associates



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] Fwd: [Owasp-igoat-project] OWASP iGoat version 2.0 RELEASED!!!

[Kenneth R. van Wyk]

Greetings SC-L,

For all of you who are interested in mobile app sec (or interested in learning 
more about it), we released OWASP iGoat version 2.0 today. See the details in 
our announcement below.

Cheers,

Ken van Wyk

Begin forwarded message:

> From: "Kenneth R. van Wyk" 
> Subject: [Owasp-igoat-project] OWASP iGoat version 2.0 RELEASED!!!
> Date: February 26, 2013 2:48:48 PM EST
> To: "owasp-igoat-proj...@lists.owasp.org" 
> 
> 
> OWASP iGoat Project:
> 
> Thanks to iGoat lead developer, Sean Eidemiller, it gives me great pleasure 
> to announce the immediate release of OWASP iGoat version 2.0! See the project 
> web site at: 
> 
> https://www.owasp.org/index.php/OWASP_iGoat_Project
> 
> for more information, or go directly to the source repository to download at:
> 
> http://code.google.com/p/owasp-igoat/
> 
> 
> The OWASP iGoat tool is a stand-alone iOS app (distributed solely in source 
> code) designed to introduce iOS developers to many of the security pitfalls 
> that plague poorly-written apps. Like its namesake, OWASP's WebGoat tool, 
> iGoat is intended to teach software developers about these issues by stepping 
> them through a series of exercises, each of which focuses on a single aspect 
> of iOS security.
> 
> OWASP iGoat is an ideal tool to use in a classroom setting to teach iOS 
> developers (and technically minded IT Security staff with at least some 
> exposure to object oriented programming).
> 
> Exercises include many typical problem issues (and their solutions) including:
> - Securing sensitive data in transit
> - Securing sensitive data at rest
> - Securely connecting to back-end authentication services
> - Side channel data leakage (e.g., system screen shots, cut-and-paste, and 
> keystroke logging via the autocorrection feature)
> - Making use of the system keychain to store small amounts of consumer-grade 
> sensitive data
> 
> 
> New to version 2.0:
> 
> - iGoat is now a true Universal app, so it builds and runs on iPhones, iPod 
> Touches, as well as iPads. Full screen views are supported on all of these 
> devices. (It also runs on the iPhone simulator included with XCode, of course 
> -- which is ideal for a classroom environment.)
> 
> - A few "behind the scenes" improvements were made to the iGoat platform 
> itself, making it easier to work with and develop new exercises. These 
> include:
>   o Storyboards for main screen navigation.
>   o ARC support for object memory management.
> 
> - General code clean-ups.
> 
> 
> Requirements:
> 
> To build and run iGoat, you'll need a Mac running OS X (real or virtual 
> machine), with XCode installed. iGoat was built for Mountain Lion, but should 
> run fine on any OS X newer than Snow Leopard. We recommend the latest XCode 
> and built iGoat using XCode version 4.6. Similarly, iGoat was built on iOS 
> 6.1, but should be backwards compatible with at least version 5.x. 
> 
> 
> We invite the OWASP community to download and try iGoat, and we welcome your 
> suggestions for improvements. We're always looking for willing participants 
> to contribute to the project as well!
> 
> Cheers,
> 
> Ken van Wyk
> OWASP iGoat Project Leader
> 
> 
> 
> ___
> Owasp-igoat-project mailing list
> owasp-igoat-proj...@lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-igoat-project



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] Apple Employees Hacked By Visiting iPhoneDevSDK - Mac Rumors

[Kenneth R. van Wyk]

Here is an interesting twist to the recent Apple hack. I hope no SC-Lers are 
using iphonedevsdk!

http://www.macrumors.com/2013/02/19/apple-employees-hacked-by-visiting-iphonedevsk/


Cheers,

Ken van Wyk
KRvW Associates, LLC



___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] Pinning Cheat Sheet - OWASP

[Kenneth R. van Wyk]

If you're looking for a concise yet detailed guide to certificate pinning, 
along with code examples, look no further:

https://www.owasp.org/index.php/Pinning_Cheat_Sheat 

Superb work by Jeffery Walton et al. Thanks all!


Cheers,

Ken

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

Follow us on Twitter at: @KRvW or @KRvW_Associates



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] There's no magic pill for security - Computerworld

[Kenneth R. van Wyk]

Happy New Year, SC-L readers,

My monthly column in Computerworld hit the web today, and I thought some of you 
might find it useful (perhaps in talking with senior management). 

http://www.computerworld.com/s/article/9235776/There_s_no_magic_pill_for_security
 

Food for thought, anyway, as we start off our 2013 activities.

Cheers,

Ken

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

Follow us on Twitter at: @KRvW or @KRvW_Associates



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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] New 64-bit Linux Rootkit Doing iFrame Injections - Securelist

[Kenneth R. van Wyk]

Hmmm, an interesting twist in the Linux malware world -- and a bit of a 
collision of traditional OS-level malware and app-level security woes.  This 
latest Linux rootkit (below) can inject an iFrame into any HTTP response sent 
from an infected web server. Thus, it can be used to spew malware into 
susceptible web browser clients, and appear as though the drive-by infection is 
coming from a web app hosted on the infected site.

See full write-up below.

https://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections
 

Oh, and happy Thanksgiving to all you USA folks out there.

Cheers,

Ken

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

Follow us on Twitter at: @KRvW or @KRvW_Associates



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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] ANNOUNCING: MobAppSecTri Scholarship Program

[Kenneth R. van Wyk]

Hey SC-Lers,

We're giving away to a few deserving Mobile App Developers a small number of 
FREE tickets to our Mobile App Sec Triathlon. If you know any deserving 
students / interns, point them in our direction for a chance to get a free seat.

See 
http://mobappsectriathlon.blogspot.com/2012/09/announcing-mobappsectri-scholarship.html
 for details.

Cheers,

Ken van Wyk




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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] OWASP Cheat Sheet for iOS Developers

[Kenneth R. van Wyk]

Hi SC-L,

Hey, it dawned on me that I never posted a pointer to the OWASP iOS Developer 
Cheat Sheet that was published a couple months ago.

https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet

As the initial author of the cheat sheet, I'd sure love to get feedback and -- 
better yet -- participation on it. Like all OWASP docs, it's open source, so 
find things you want to add/improve and join in.

Either way, I hope you find it useful.

Cheers,

Ken

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

Follow us on Twitter at: @KRvW or @KRvW_Associates



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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] Mobile app security blog, FYI

[Kenneth R. van Wyk]

Greetings SC-L,

FYI, Gunnar Peterson (@OneRaindrop) and I (@KRvW) launched a blog last month on 
the topic of mobile app security. The blog can be found at 
http://mobappsectriathlon.blogspot.com

Full disclosure: On the blog, you will see advertisements for the 
MobAppSecTriathlon event that Gunnar and I are running in November, but the 
blog is free and we hope you'll find the topics we post on to be interesting 
and thought provoking. Even if you have no interest in joining us for the 
Triathlon event, we hope you'll stop by and check out the blog. Registered and 
authenticated Google+ users may submit comments as well, which we welcome.

Cheers,

Ken

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

Follow us on Twitter at: @KRvW_Associates



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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] OWASP Cheat Sheet for iOS App Developers

[Kenneth R. van Wyk]

Title: OWASP Cheat Sheet -- iOS App Developers
Author:  Kenneth R. van Wyk
Source: OWASP - the Open Web Application Security Project
Date Published: 2012-07-17

Excerpt:

"This document is written for iOS app developers and is intended to provide a 
set of basic pointers to vital aspects of developing secure apps for Apple’s 
iOS operating system. It follows the OWASP Mobile Top 10 Risks list."

Full article at: https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet


Cheers,

Ken

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

Join us for our 2012 Mobile App Sec Triathlon: www.mobileappsectriathlon.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] Test

[Kenneth R. van Wyk]

Foo

Cheers,

Ken

___
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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] Column -- "New Terrorist Profile: Phone Users"

[Kenneth R. van Wyk]

Greetings,

FYI, Gary McGraw has a column on darkreading this month about eavesdropping on 
telephone conversations -- see the full column at:

http://www.darkreading.com/document.asp?doc_id=96927&WT.svl=column1_1
 
It helps put things into context when considering security features for our 
apps.

Cheers,

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


pgpscIgZ5xJhO.pgp
Description: PGP 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

[SC-L] WSJ.com - Tech Companies Check Software Earlier for Flaws

[Kenneth R. van Wyk]

I saw an interesting Wall Street Journal article today that talks about 
companies adopting software security practices.  Complete story can be found 
at:

http://online.wsj.com/public/article/SB114670277515443282-B59kll7qXrkxOXId1uF0txp8NFs_20070504.html?

The article cites a couple of companies that are starting to seriously use 
some static code analysis tools (Coverity and Fortify) to scan their src 
trees for security defects.  Although it doesn't address much in the way of 
design-time security activities, it's a good start and it's encouraging to 
see this sort of coverage in mainstream media.

I really liked this quote - "In effect, software makers are now admitting that 
their previous development process was faulty. While banks and other 
companies that deal with sensitive customer data began to build security into 
software development in the late 1990s, Microsoft Corp. and other software 
makers are only now in the middle of revamping their software-writing 
processes. "

Cheers,

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


pgpHMXwUbgpNJ.pgp
Description: PGP 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] HNS - Biggest X Window security hole since 2000

[Kenneth R. van Wyk]

On Thursday 04 May 2006 12:40, Gadi Evron wrote:
> Hmm, I think this was fixed in earlier X versions.

Not impossible, but the article clearly indicated that it's in 6.9.0 and 
7.0.0, which are the most current in general circulation, I believe.

But, some bugs are so important that they deserved to be fixed more than once.  
It sure wouldn't be the first time that a bug found its way back into a src 
tree.

Cheers,

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


pgpSwossK0g5Q.pgp
Description: PGP 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

[SC-L] HNS - Biggest X Window security hole since 2000

[Kenneth R. van Wyk]

Stories about this (below) X bug and the DHS-sponsored project that found it 
have been floating around the net all week.  This story caught my eye, 
though:

http://www.net-security.org/secworld.php?id=3994

The author claims, "This flaw, caused by something as seemingly harmless as a 
missing closing parenthesis, allowed local users to execute code with root 
privileges, giving them the ability to overwrite system files or initiate 
denial of service attacks."

So, it sounds like a single byte change in the entire X src tree could fix a 
bug that could give an attacker complete control of a system.  Lovely...

Cheers,

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


pgpyqSfoo0SaU.pgp
Description: PGP 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

[SC-L] HNS - A Modular Approach to Data Validation in Web Applications

[Kenneth R. van Wyk]

FYI, I saw a paper this morning by Stephen de Vries describing "A Modular 
Approach to Data Validation in Web Applications".  The paper claims that the 
benefits of their approach include:

"Implementing such a modular approach contributes to the application 
being
loosely coupled and ensures that it can safely be extended and 
components
reused, without incurring unnecessary development time to re-implement
validation routines. "

A full abstract and a link to the (PDF format) paper can be found here:

http://www.net-security.org/article.php?id=915

Cheers,

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


pgpwGM9WQEi8o.pgp
Description: PGP 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

[SC-L] AJAX: Is your application secure enough?

[Kenneth R. van Wyk]

Another interesting paper passing through slashdot today is "AJAX: Is your 
application
secure enough?"  You can find it at
http://www.darknet.org.uk/2006/04/ajax-is-your-application-secure-enough/

Looks to me like an interesting read, fwiw.  Much as I like the interactiveness 
that AJAX
brings to the game, I can't help but think that there's tons of room for major 
security
mistakes to be made, if only due to the complexity of knowing what's going on 
at each tier
of the app all the time.

Cheers,

Ken
-- 
Kenneth R. van Wyk
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

[SC-L] Underhanded C contest

[Kenneth R. van Wyk]

Those interested in static source analysis (with or without tools) may be 
interested in the
2006 "Underhanded C Contest".  Details are available at 
http://www.brainhz.com/underhanded/

Sigh...

Cheers,

Ken
-- 
Kenneth R. van Wyk
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

[SC-L] Software security efforts at DTCC

[Kenneth R. van Wyk]

FYI, some more mainstream coverage of software security issues.  This article --
http://www.securitypipeline.com/183702555;jsessionid=SF0AM1XSETTOEQSNDBECKICCJUMEKJVN
-- describes some software security process improvements under way at the 
Depository Trust
and Clearing Company (DTCC).

What I find encouraging is hearing about companies that are bringing their 
security and
software development efforts together.  YMMV...

Cheers,

Ken
-- 
Kenneth R. van Wyk
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

[SC-L] CFP -- HICSS 2007

[Kenneth R. van Wyk]

Greetings SC-L subscribers:

FYI, a Call for Participation for the Hawaii International Conference on System 
Sciences
(HICSS) Secure Software Architecture, Design, Implementation and Assurance 
(SSADIA)
Minitrack is out.  The conference takes place 3-6 January 2007 in Waikoloa on 
the Big Island
of Hawaii.

The CFP can be found below.

Cheers,

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

==
HICSS-40: Call for Papers

Secure Software Architecture, Design, Implementation and Assurance (SSADIA) 
Minitrack
Hawaii International Conference on System Sciences
Waikoloa, Big Island, Hawaii, January 3-6, 2007

Call For Participation
The Secure Software Architecture, Design, Implementation and Assurance 
minitrack focuses on
the research and automation required to develop secure software systems that do 
not
compromise other system properties such as performance or reliability. Current 
security
engineering methods are demonstrably inadequate, as software vulnerabilities 
are currently
being discovered at the rate of over 4,000 per year. These vulnerabilities are 
caused by
software designs and implementations that do not adequately protect systems and 
by
development practices that do not focus sufficiently on eliminating 
implementation defects
that result in security flaws. An opportunity exists for systematic improvement 
that can
lead to secure software architectures, designs, and implementations.

The following topics are appropriate topics for research papers:
- Static analysis tools and techniques for detecting security flaws and software
vulnerabilities in source or binary code
- Dynamic analysis tools for detecting security flaws and software 
vulnerabilities in source
or binary code
- Model checking tools for detecting security flaws and software 
vulnerabilities in software
systems
- Software architectures and designs for securing against denial-of-service 
attacks and
other software exploits
- Coding practices for improved security and secure library implementations
- Computational security engineering
- Other tools and techniques for reducing or eliminating vulnerabilities during 
development
and maintenance

Co-Chairs
Sven Dietrich, CERT
Daniel Plakosh, CERT/CC
Robert C. Seacord, CERT/CC

Address email to the minitrack chairs to [EMAIL PROTECTED]

Program Committee
Julia Allen, SEI/CMU
Hal Burch, CERT/CC
Brian Chess, Fortify Software
Bob Fleck, Secure Software
Michael Howard, Microsoft
Derek M. Jones, Knowledge Software Ltd
Alan Krassowski, Symantec
Fred Long, University of Wales, Aberystwyth
Tom Longstaff,  CERT
Robert Martin, MITRE
Leon Moonen, Delft University of Technology
James W. Moore, MITRE
Samuel Redwine, James Madison University
David Riley, University of Wisconsin - La Crosse
John Steven, Cigital
Carol Woody, CERT
Kenneth R. van Wyk, KRvW Associates, LLC

Paper Review And Proceedings Publication
HICSS conferences are devoted to the most relevant advances in the information, 
computer,
and system sciences, and encompass developments in both theory and practice. 
Accepted papers
may be theoretical, conceptual, tutorial, or descriptive in nature. Submissions 
must not
have been previously published. Submissions undergo a double-blind peer referee 
process.
Those selected for presentation at the conference will be published in the 
HICSS-40
conference proceedings.

Instructions For Paper Submission
HICSS papers must contain original material not previously published nor 
currently submitted
elsewhere.
It is recommended that authors contact the Minitrack Chair(s) by email for 
guidance
regarding appropriate content.
HICSS will conduct double-blind reviews of each submitted paper.
Submit full paper according to detailed author instructions to be found on the 
HICSS web
site (http://www.hicss.hawaii.edu/hicss_40/apahome40.htm ) by May 1.
The preferred format for papers submission is PDF.

Important 2006 Dates
June 15, 2006 - Authors may contact Minitrack Chairs for guidance and 
indication of
appropriate content at any time before June 15.
August 15, 2006 - Deadlines to submit full papers. All papers will be submitted 
in double
column publication format and limited to 10 pages including diagrams and 
references. Papers
undergo a double-blind review.
September 15, 2006 - Authors receive notification regarding paper acceptances 
through the
review system, not from the Minitrack Chairs. Acceptance may be conditional; 
revisions may
be requested before final acceptance of paper. Attendance by at least one 
author and
presentation of the paper at the conference is a requirement of acceptance.
September 16, 2006 - Authors submit final version of papers following author 
instructions
posted on this site. At least one author of each paper must register by this 
date with
specific plans to attend the conference to present the paper. Early 
registration fee applies
until this date.
September 17, 2006 - General registration

[SC-L] ZDNET: LAMP lights the way in open-source security

[Kenneth R. van Wyk]

Interesting article out on ZDNet today:

http://www.zdnetasia.com/news/security/0,39044215,39315781,00.htm

The article refers to the US government sponsored study being done by Stanford 
University,
Symantec, and Coverity.  It says, "The so-called LAMP stack of open-source 
software has a
lower bug density--the number of bugs per thousand lines of code--than a 
baseline of 32
open-source projects analyzed, Coverity, a maker of code analysis tools, 
announced Monday."

This surprised me quite a bit, especially given LAMP's popular reliance on 
scripting
languages PHP, Perl, and/or Python.  Still, the article doesn't discuss any of 
the root
causes of the claimed security strengths in LAMP-based code.  Perhaps it's 
because the
scripting languages tend to make things less complex for the coders (as opposed 
to more
complex higher level languages like Java and C#/.NET)?  Opinions?

Cheers,

Ken
-- 
Kenneth R. van Wyk
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

[SC-L] AJAX security paper

[Kenneth R. van Wyk]

FYI, here's a pointer to a just-published paper on AJAX security.  Hope you 
find it useful,
particularly in light of AJAX's quick rise in popularity.

http://www.it-observer.com/articles/1062/ajax_security/

Cheers,

Ken
-- 
Kenneth R. van Wyk
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

[SC-L] Book review: Essential PHP Security

[Kenneth R. van Wyk]

I know that a lot of the folks on this list would consider the words "PHP 
Security" to be an oxymoron.  That said, there's a book out on the subject, 
and it's been reviewed on /.  The review can be found at:

http://books.slashdot.org/books/06/02/13/1426220.shtml

Cheers,

Ken van Wyk

P.S. It was nice to see a few SC-L folks at S3 in San Diego last week.
-- 
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] Bugs and flaws

[Kenneth R. van Wyk]

This thread sure has opened up some lively debate...

Gary McGraw wrote:


As a matter of practice, I usually use the terms that you suggested as
modifiers and say:

implementation bug
design flaw
software defect
 

FWIW, I like to use the nomenclature "security defect" as an 
all-encompassing term, irrespective of design vs. implementation.  Then, 
quite frankly, I think that the choice of "bug" or "flaw" is far less 
important than putting them into the appropriate _context_ -- which is 
why I also generally use the above "implementation bug" and "design flaw". 

I do think that the distinction is important, even though I agree with 
the thought that it's pretty much of a continuum across the spectrum.  
From a pragmatic viewpoint, one of the important distinctions is how 
one would go about rectifying the defect.  An implementation bug can 
often times be fixed in a couple lines of code (e.g., strncpy vs. 
strcpy), whereas a design flaw may well require going "back to the 
drawing board" and fixing an underlying architectural weakness.  This 
is, of course, irrespective of how the problem was found.


I'll also point out that none of three of the above terms even mention 
security.  They could be functional defects as well as security defects, 
which is just fine, IMHO.


Cheers,

Ken van Wyk

___
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] Administrative: whitelisting on SC-L

[Kenneth R. van Wyk]

Hi SC-L folks:

I don't mean to intrude in the "bug and flaw" debate, but I do want to make 
sure that you're all aware of the whitelisting that I'm doing on the list 
these days, since I switched the list management from Majordomo to Mailman.  

Specifically, in order to cut down on spam, I have Mailman set to drop any 
posting sent from _any_ address that is not explicitly subscribed to the 
list.  That means, for example, if you subscribe via an email exploder or 
alias at your site, that your submissions get automatically /dev/nulled.

The solution, for anyone that wants to post and is subscribed similarly to the 
above scenario, is to subscribe your personal address and set it to NOT 
receive SC-L postings.  That way, your mail alias/exploder will continue to 
function as you set it up, AND you'll be able to post.

Since I get ZERO notification when messages (mostly spam) are dropped by the 
whitelist, I have no way of knowing who is in this situation.  So, if you 
want the ability to post, drop me a note and I'll be happy to set you up with 
a no-mail subscription.  (Don't worry, you won't/shouldn't get duplicates.)

Cheers,

Ken van Wyk
SC-L Moderator
___
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] eWeek: AJAX Poses Security, Performance Risks

[Kenneth R. van Wyk]

Any AJAX experts here want to comment on the eWeek article cited below?

http://www.eweek.com/article2/0,1895,1916673,00.asp

It claims, among other things that, "AJAX dramatically increases the amount of 
XML network traffic being transmitted, exposing applications to Web services 
vulnerabilities".

Cheers,

Ken van Wyk
-- 
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

[SC-L] eWeek says "Apple's Switch to Intel Could Allow OS X Exploits"

[Kenneth R. van Wyk]

Interesting article, I suppose, but I'm not convinced of its conclusion:

http://www.eweek.com/article2/0,1895,1915923,00.asp

The article claims that Apple's use of Intel chips will result in more 
software exploits because, "'Attackers have been focused on the [Intel] x86 
for over a decade. Macintosh will have a lot more exposure than when it was 
on PowerPC,' said Oliver Friedrichs, a senior manager at Symantec Corp. 
Security Response."

I was hoping to find some hint of a hardware architectural feature that the 
powerpc has that provided an additional means of protection, but the article 
mentions none.  Instead, the only reason that it cites for the (presumed) 
increase in software exploits is attackers' knowledge and experience base.

After all, didn't attackers also have access to powerpc systems to build 
attacks on during the same timeframe that Symantec suggests?  Does the 
powerpc architecture provide some inherent protection against (say) stack 
smashing than the x86 does?

Am I missing something here?

Cheers,

Ken
-- 
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] Any interest in an informal SC-L BoF at S3?

[Kenneth R. van Wyk]

Kenneth R. van Wyk wrote:

I'm not sure if there's enough critical mass here AND going to S3 
(http://www.s3-con.com), but it's worth a shot...


Oops, it was pointed out to me that my citation above is incorrect, 
sorry.  The correct URL for the Software Security Symposium is in fact 
http://www.s-3con.com   Sorry for any confusion, and I hope to see some 
SC-L folks out in sunny La Jolla.  Please stop by and say hello if 
you're there, even if you can't attend our BoF.


Cheers,

Ken van Wyk

___
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] (fwd) Secure Java apps on Linux using MD5 crypt

[Kenneth R. van Wyk]

The title ("Secure Java apps on Linux using MD5 crypt") is a bit misleading, 
since the article is really about using a native Java MD5 module for 
authenticating Linux apps, but it's still worth a look-see for any Java/Linux 
folks, FYI:

http://www-128.ibm.com/developerworks/linux/library/l-md5crypt/?ca=dgr-lnxwLinuxCrypt

Cheers,

Ken van Wyk
-- 
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

[SC-L] Any interest in an informal SC-L BoF at S3?

[Kenneth R. van Wyk]

Hi folks,

I'm not sure if there's enough critical mass here AND going to S3 
(http://www.s3-con.com), but it's worth a shot...

If anyone is interested in an informal SC-L gathering for drinks and/or dinner 
at the Software Security Symposium in La Jolla, California next month, I'd be 
happy to volunteer to organize one.  It'll be a self-pay thing, so please 
bring some cash so that we can divide the bill easily.

When/where:

Tuesday, 7 Feb 2006
6-8 PM (UTC -0700)
Rock Bottom Brewery
8980 Villa La Jolla Drive
La Jolla, CA 92037

The Rock Bottom is just a stone's throw down the road from the conference 
hotel.  It's across the highway interchange, so it might be a bit of a 
challenging walk, but it's a very short drive.

No sales droids, please.  Just an informal chat about software security (or 
other topics of interest) for anyone interested in joining in.

If you want to attend, please let me know.  Once I have sufficient attendees 
(say 4 or more people), I'll confirm the arrangements with them directly.  
Otherwise, I'll just cancel and hope that we get enough people at the next 
event.

Hope to see a few SC-Lers there!

Cheers,

Ken van Wyk
--
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

[SC-L] DHS funding open source security scanning

[Kenneth R. van Wyk]

FYI, interesting article out on ZDNet (full text at
http://news.zdnet.com/2100-1009_22-6025579.html) announcing the U.S. Dept. of 
Homeland
Security funding of a joint Stanford/Symantec/Coverity project over three 
years.  The
project aims to provide periodic scans of popular open source software using 
Coverity's
commercial scanner and Symantec's security intelligence service.

Cheers,

Ken van Wyk
-- 
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

[SC-L] ZDNet: Microsoft to hunt for new species of Windows bug

[Kenneth R. van Wyk]

Following the recent Microsoft WMF flaw, there's an article in ZDNet talking 
about how
Microsoft is now going to "scour its code to look for flaws similar to a recent 
serious
Windows bug and to update its development practices to prevent similar problems 
in future
products."  The full text of the article can be found at:
http://news.zdnet.com/2100-1009_22-6024778.html

Cheers,

Ken
-- 
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

[SC-L] IEEE Spectrum: The Exterminators

[Kenneth R. van Wyk]

I saw an interesting IEEE Spectrum article today about the software security 
work being done by Peter Amey and the folks over at Praxis.  Full text can be 
found at:

http://www.spectrum.ieee.org/sep05/1454

Cheers,

Ken van Wyk
-- 
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] Managing the insider threat through code obfuscation

[Kenneth R. van Wyk]

On Thursday 15 December 2005 09:26, Jose Nazario wrote:
> if the person can develop exploits against the holes in the code, what
> makes you think they can't fire up a runtime debugger and trace the code
> execution and discover the same things?

Nothing makes me think that at all; in fact, I was quite skeptical of the 
various product claims, which is why I wanted to hear about others' 
experience with them.

Cheers,

Ken
-- 
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

[SC-L] Managing the insider threat through code obfuscation

[Kenneth R. van Wyk]

This morning, an article caught my attention -- "Managing the insider threat 
through code obfuscation", 
http://www.itmanagersjournal.com/article.pl?sid=05/12/13/1736253

The article's premise is that, because attackers can find out a great deal 
about the internals of databases and such by decompiling bytecode (in Java 
and .NET), bytecode should be obfuscated to hide its internal details.  The 
article points to several commercial bytecode obfuscation products: 
http://www.devdirect.com/ALL/OBFUSCATIORS_PCAT_2014.aspx

I hadn't heard of this approach before, although I'm quite familiar with how 
easy it is to decompile Java bytecode.  My questions for the group are:

o Anyone here have any good/bad experiences with bytecode obfuscation?
o What is the impact on performance of the bytecode?
o How about compatibility with various JVMs?
o How much protection do these obfuscators really provide?
o Is this all just a bunch of product marketing hooey?

Well, at least the article uses the term "threat" correctly...

Cheers,

Ken van Wyk
---
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] Countering Trusting Trust through Diverse Double-Compiling

[Kenneth R. van Wyk]

On Wednesday 14 December 2005 16:40, David A. Wheeler wrote:
> I've written a paper on an approach to counter this attack. See:
>   "Countering Trusting Trust through Diverse Double-Compiling"
>   http://www.acsa-admin.org/2005/abstracts/47.html

Thanks for sharing it here, David.

> Here's the abstract:
> "... Simply recompile the purported source code twice: once with a second
> (trusted) compiler, and again using the result of the first compilation.
> If the result is bit-for-bit identical with the untrusted
> binary, then the source code accurately represents the binary. ..."

This reminded me of an old class of PC viruses (circa 1992) that evaded 
detection by file scanners by hooking the S-DOS  file read interrupt and 
returning the original, uninfected version of infected files whenever a 
program opened up an infected file for reading.  It tricked a lot of file 
scanners at the time.  If I'm not mistaken, it was the DIR-II family of 
viruses.  I'm sure that you've taken that sort of evasive action into 
account, but I thought that I'd mention it here for the SC-L folks.

Heck, by today's rather loose definitions of what a rootkit is, perhaps the 
DIR-II family was the first malware to feature rootkit-like stealth 
techniques.

Cheers,

Ken van Wyk
-- 
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

[SC-L] Intel turning to hardware for rootkit detection

[Kenneth R. van Wyk]

FYI, eWeek has an interesting article on Intel's "System Integrity Services," 
which aims to add hardware level protection against rootkits.  Now, it seems 
to me that they're bundling all sorts of nasty critters in with their 
definition of "rootkit" but it's worth reading, IMHO.  

The detection mechanism seems to primarily be looking primarily for non-OS 
software modifying OS inhabited memory blocks.  Wonder how they're definining 
(and maintaining the definition) of each...  I also wonder how it'll impact 
near-OS software installations like, say, device drivers, authentication 
plug-ins, and other things that need to poke pretty deeply into the OS in 
order to install.

Anyway, here's a URL to the article.

http://www.eweek.com/article2/0,1895,1900533,00.asp

Cheers,

Ken van Wyk
-- 
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

[SC-L] Missing URL -- ZDNet: Attackers switching to applications, media players

[Kenneth R. van Wyk]

Sorry, I neglected to include the URL for the story that I cited.  It can be 
found at:

http://news.zdnet.com/2100-1009_22-593.html?tag=zdfd.newsfeed

Cheers,

Ken


___
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] ZDNet: Attackers switching to applications, media players

[Kenneth R. van Wyk]

FYI, interesting article on ZDNet today citing a SANS study.  The article says, 
among other
things, "Online criminals shifted their attacks in 2005 from operating systems 
such as
Windows to media players and software programs, according to a study released 
Tuesday."

If the study's findings are correct, then it places an emphasis on 
organizations' software
security efforts.  IMHO, it's certainly not about "the perimeter" anymore (if 
it ever really
was).

Cheers,

Ken

P.S. On a list administrative front, it appears that the Mailman list manager 
seems to be
working pretty well for us.  One significant change that could impact you 
subscribers is
that I've configured Mailman to discard incoming messages from anyone that is 
not subscribed
to SC-L.  So, if you use a local mail alias to read your SC-L, you might have 
difficulties
submitting messages to the group. If that's the case, just drop me a note and 
I'll step you
through setting things up so that your submissions don't get discarded.  (The 
discarding has
done wonders for reducing the amount of spam in my life.)

-- 
Kenneth R. van Wyk
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

[SC-L] Slashdot | Developing Securely In Windows

[Kenneth R. van Wyk]

FYI, there's a review (by Jim Holmes) of Keith Brown's book, "The .NET 
Developer's Guide to Windows Security" available out on Slashdot at:

http://books.slashdot.org/books/05/11/21/1442228.shtml

The review summary reads, "Terrific coverage of how to go about securely 
developing .NET software".

Cheers,

Ken van Wyk
-- 
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

[SC-L] Administrative: SC-L changes

[Kenneth R. van Wyk]

Greetings all,

FYI, I have moved the securecoding.org site and SC-L mailing list over to a
different host.  The new host should be quite a bit faster, as it's used by a
much (!) smaller number of domains than the old one.

More importantly, at least for SC-L, is that I've changed the mailing list
manager from Majordomo to Mailman.  That means that the user interface for
subscribing, unsubscribing, digest vs. normal, etc., is now completely
different.  Additionally, Mailman automatically handles archiving of the
list, so the list traffic (from now on) will be nicely archived for easy
viewing and such.

For any and all subscription changes, just point your browsers to
http://www.securecoding.org/list/ and you'll see a link to the Mailman page.
For those so inclined, it should now be easier for you to change between
digest and non-digest format for the list.  Mailman makes that quite easy for
users.  Please try to follow the instructions on the Mailman page.  If that
doesn't work, contact me and I'll be happy to make the change for you.

Lastly, I did a bit of testing of Mailman before doing the cutover, but I'm by
no means a Mailman expert (yet).  I _hope_ that all goes smoothly, but I ask
you all to be patient if there are any unexpected burps and such.

Thanks for your patience.

Cheers,

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


___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
http://krvw.com/mailman/listinfo/sc-l

[SC-L] Fwd from CIO Update: Why is application security so elusive?

[Kenneth R. van Wyk]

FYI, there's a column in CIO Update by Ed Adams exploring some of the reasons 
why secure software is so hard to find.  Unlikely to be anything new to SC-L 
readers, but it could be worth a quick read in any case.  In particular, his 
recommendations (to his presumably mostly CIO audience) are quite different 
than what you might expect to find, say, here on SC-L.  In any case, you can 
find the article at: http://www.cioupdate.com/trends/article.php/3548306

(Full disclosure: CIO Update is run by Jupiter Media, who also owns the site 
(eSecurityPlanet.com) where I'm a monthly columnist.)

Cheers,

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

[SC-L] SC-L changes

[Kenneth R. van Wyk]

Greetings SC-L folks,

Although it's been particularly quiet here recently, I've also been moving the 
list over to a new system, which has caused some additional "outages".  
(Read: tree fell in the forest and no one heard it.)  In any case, the new 
system should be fully functional in the next day or two, so on the off 
chance that anyone does post anything, please bear with me while I get things 
up and running.  I'll probably send out one or two tests to ensure that 
things are flowing.  Sorry for any inconvenience...

Cheers,

Ken van Wyk
SC-L moderator

[SC-L] Wall Street Journal article on Software Security and upcoming events

[Kenneth R. van Wyk]

Hi all,

FYI, a couple of interesting things going on in the software security space 
that those here on SC-L might appreciate:

- Good article/interview in yesterday's Wall Street Journal on the topic of 
Software Security.  The interview is with Gary McGraw, and I'm sure that no 
one here will be too surprised by the content.  It's just great to see that 
kind of visibility and attention being given to Software Security.  Check it 
out (registration/subscription required) at 
http://online.wsj.com/article/0,,SB112128453130584810,00-search.html?KEYWORDS=cigital&COLLECTION=wsjie/archive
(Or just find a paper copy -- you know, the kind that our grandparents used to 
read. ;-)

- A couple of upcoming, fairly mainstream IT Security conferences both have 
numerous Software Security sessions on their agendas (including, for full 
disclosure, my own sessions at each).  I'm refering to CSI's upcoming 32nd 
annual conference (14-16 November in Washington, DC) and SANS's Silicon 
Valley event (24-30 September in San Jose, CA).  Here too, it's encouraging 
to me to see software security sessions prominently on the programs of these 
traditionally IT Security focused events.

Cheers,

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

[SC-L] ANNOUNCING: 2nd US OWASP AppSec Conference - Oct 11-12 - Near DC

[Kenneth R. van Wyk]

[Ed. Crossposted, as I thought that it was relevant here as well.  KRvW]

Originally From: Dave Wichers <[EMAIL PROTECTED]>

Dear Colleague,

OWASP is proud to announce its second annual U.S. Application Security 
Conference. This year's conference will be held October 11-12 at the NIST 
campus in Gaithersburg, Maryland near Washington, DC. This location was 
chosen in order to encourage government, industry, and academia to get 
together and talk about the pressing problems we all face in application 
security today. Our first conference last year in NY had almost 150 
attendees. We are expecting to have almost double that at this year's 
conference. NIST's auditorium can hold 700 people so we have plenty of room 
this year. Lets fill it up!

A few firsts for our 2nd US conference:
- Sponsorship: This conference is being sponsored by the National Institute 
of Standards and Technology (NIST)
- Significant Government Participation: Representives of various government 
agencies, including NIST and the Department of Homeland Security (DHS) will 
be speakers at the conference
- Training: A 1-day training course on the Fundamentals of Web Application 
Security is being offered the day prior to the conference
- Its not being held on a weekend :-)

Full details on the conference are available on the OWASP website at 
http://www.owasp.org/conferences/appsec2005dc.html

This year's speakers include:

a.. Joe Jarzombek - Director of Software Assurance at the Department of 
Homeland Security
a.. Ron Ross - FISMA Project Lead - NIST
a.. Jeff Williams - OWASP Chair and CEO Aspect Security
a.. Jack Danahy - CEO Ounce Labs
a.. Paul Black - SAMATE Project Lead and OWASP Conference Sponsor - NIST
a.. Diniz Cruz - OWASP .NET Project Lead
a.. Arian Evans - OWASP Tools Project Lead - FishNet Security
a.. Jeremy Poteet - Author of Canning SPAM - CSO appDefense

OWASP's AppSec conferences are dedicated to real-world application security 
issues and solutions. You'll learn all aspects of application security, 
including people, process, and technology perspectives.

You'll hear presentations on topics like:

  - DHS plans for Software Assurance
  - Status of the Federal Information Security Management Act (FISMA) 
Project
  - A Business Case for Software Assurance
  - Attacking Web Services
  - .NET Security
  - Software Assurance Metrics
  - A Survey of Application Security Tools
  - Details on the new OWASP Guide v2
  - Details on the OWASP .NET Project
  - Defending a High Profile Political Web Site
  - How to Select an Application Security Assessment Vendor

The exact agenda is still being developed and will be posted to the site as 
soon as possible.

REGISTRATION DETAILS: As a non-profit charitable organization, and with 
NIST's sponsorship, OWASP has been able to keep the cost to $300 per seat if 
you are able to register prior to Sept. 10, 2005. The cost to government 
employees is only $250 prior to Sept. 10th.

Registration information is available at: 
http://www.owasp.org/docroot/owasp/Registration/index.jsp

PLEASE NOTE THAT ALL TICKETS ARE NON REFUNDABLE TO REDUCE ADMINISTRATION
COSTS

FOUNDATIONS OF APPLICATION SECURITY COURSE - Oct 10: OWASP has arranged to 
have a one-day hands on Web Application Security training course the day 
prior to the conference. This one day class will be held at the nearby 
Holiday Inn and is only $600 for conference attendees. Registration for this 
course can be done via the conference registration page.

More details on this training course is available at: 
http://www.owasp.org/conferences/appsec2005dc/training.html

EVENING SOCIAL EVENT - Oct 11: An optional dinner event is being held at the 
Holiday Inn Gaithersburg, which is the same location where the training is 
to be held on the 10th, and where discounted rooms are being made available 
to all conference attendees (see Accommodations below).

This event involves a dinner at the hotel from 7-9 PM, followed by drinks at 
O'Malley's Irish Pub right in the hotel or out by the hotel's indoor pool 
adjacent to the pub. We hope to see all of you there as this is a great 
chance to mingle and meet many members of the OWASP community.

ACCOMODATIONS: Information about local accomodations, including reduced rate 
rooms at the nearby Holiday Inn is available at:
http://www.owasp.org/conferences/appsec2005dc/accommodations.html

If you know others that would be interested in attending the 2nd annual US 
OWASP conference, please forward them this email and let them know about 
this opportunity.

Please contact me with any questions. Looking forward to seeing you all 
there!

Thanks, Dave

Dave Wichers, OWASP Conferences Chair
The OWASP Foundation
http://www.owasp.org 

[SC-L] TechWeb - Firefox Bug Wriggles Back Into Code

[Kenneth R. van Wyk]

Some bugs are so important that they're worth fixing more than once.  ;-\

http://www.techweb.com/wire/security/164301545

Cheers,

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

[SC-L] Secure programming with the OpenSSL API, Part 2: Secure handshake

[Kenneth R. van Wyk]

FYI, there's a new(ish) article by Kenneth Ballard out on IBM's developerWorks 
site, on the topic of secure use of OpenSSL.  It's actually part 2 in a 
series, but there's a pointer there to part 1 also.  The abstract follows, 
along with the URL to the full article:

Securing the handshake during a Secure Sockets Layer session (SSL) is vital, 
since almost all of the security involving the connection is set up inside 
the handshake. Learn how to secure the SSL handshake against a man in the 
middle (MITM) attack -- in which the intruding party masquerades as another, 
trusted source. This article also introduces the concept of digital 
certificates and how the OpenSSL API handles them.

http://www-128.ibm.com/developerworks/linux/library/l-openssl2.html?ca=dgr-lnxw02SecureHandshake


Cheers,

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

[SC-L] Fwd: Novell Adds Security Company to Its Linux Mix

[Kenneth R. van Wyk]

FYI, interesting move today in the software security space -- Novell announces 
its acquisition of Immunix.  Story at 
http://www.eweek.com/article2/0,1759,1814599,00.asp

Cheers,

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

[SC-L] "Tech News on ZDNet" -- OS makers: Security is job No. 1

[Kenneth R. van Wyk]

FYI, somewhat interesting story today on ZDNet (see 
http://news.zdnet.com/2100-1009_22-5697133.html?tag=st.prev) about operating 
system makers paying more attention to security.  Note the differing (public) 
statements by Microsoft and Apple...

Being fundamentally a "glass half full" sort of person, I think that it's 
refreshing to hear that OS vendors are making their products' security a 
higher priority than it's typically been in the past.  There's also an 
implicit message here regarding a proactive software security posture vs. 
"firewall and IDS it" after the product is released.

Cheers,

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

Re: [SC-L] Why Software Will Continue to Be Vulnerable

[Kenneth R. van Wyk]

Michael Silk wrote:
I honestly don't believe that the consumers will _EVER_ care, and I
don't believe that should have to. At most maybe they should just need
to keep an eye out for a sticker, or star-rating (government approved)
or something. But as you say, 'security' is 'hard to measure', so an
approach like that won't work.
As the saying goes, give the consumer the choice between security and 
dancing pigs, and they'll pick dancing pigs every single time.  There's 
probably more than just a grain of truth to that.

Yet, despite that pessimistic outlook -- and the survey that forked this 
thread -- I do think that companies are demanding more in software 
security, even though consumers are not.  I'm not aware of surveys that 
directly address that, but it sure seems obvious to me that they are.  
Here's to wishful thinking, anyway!

Cheers,
Ken van Wyk

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

[Kenneth R. van Wyk]

Crispin Cowan wrote:
Only after such standards are established and *proven effective* is 
there any utility in enforcing the standards upon the practitioners.
Software is *not* yet at that stage.
As much as I like the bridge metaphor -- which is why I used it on the 
cover of my Secure Coding book (and then O'Reilly trademarked it) -- I 
have to agree with Crispin on this point.  The software world is not 
ready for the same sorts of rigorous standards that are applied to (many) 
other Engineering disciplines.  (For that reason, I generally avoid the term 
"Software Engineer".)  Perhaps it will get there some day, but not 
today.  IMHO...

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

[SC-L] (fwd) New mailing list announced -- MobileBugtraq

[Kenneth R. van Wyk]

FYI, this seems kind of topical -- a new bugtraq list specifically for
discussing vulnerabilities in mobile terminals.  See message below, forwarded 
from the Full-Disclosure list.

Cheers,

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

== snip ===


[Full-disclosure] MobileBugtraq Mailing List
From: "Franckl - MobileBugtraq" <[EMAIL PROTECTED]>  (MobileBugtraq)
To: full-disclosure@lists.grok.org.uk
Date: Today 07:25:14

MobileBugtraq is a new discussion mailing list about security of mobile 
terminals systems including all sorts of platforms. Topics of discussion 
might be related to hacking, protecting against break-ins, system bugs and 
exploits, etc. 

The postings in this list may be written either in English. 

To subscribe to the MobileBugtraq list, one should send an e-mail to: 
[EMAIL PROTECTED]
(just including in the main message body (no subject is needed): subscription) 

After having subscribed, one might send messages to the MobileBugtraq List at 
the address: [EMAIL PROTECTED]

See you soon to talk about mobile security and share your knowledge.

Regards,

Franckl - http://www.mobilebugtraq.com - Symbian, 3G, Drm, Bluetooth, Java, 
Windows Mobile, and a lot of fun.

Re: [SC-L] Mobile phone OS security changing?

[Kenneth R. van Wyk]

On Wednesday 06 April 2005 09:26, Michael Silk wrote:
> The last thing I want is my mobile phone updating itself. I imagine
> that sort of operation would take up battery power, and possibly cause
> other interruptions ... (can you be on a call and have it update
> itself?)

I vividly remember a lot of similar arguments a few years ago when desktop PCs 
started doing automatic updates of OS and app software.  Now, though, my 
laptop gets its updates when it's connected and when I'm not busy doing other 
things.

My main point, though, is that the status quo is unacceptable in my opinion.  
If a nasty vulnerability is found in most of today's mobile phone software, 
the repair process -- take the phone to the provider/vendor and have them 
burn new firmware -- just won't cut it.  For that matter, a lot of PDAs are 
in the same boat.

Sure, we'd all prefer better software in those devices to begin with, but as 
long as there are bugs and flaws, the users of these devices need a better 
way of getting the problems fixed.

> Personally, I would prefer a phone that doesn't connect to the
> internet at all rather than a so called 'secure' phone.

For the most part, those days are over.

> From reading the article it seems like the application asks to be
> installed, (is that correct?) so it doesn't seem like that big of a
> problem [unless phones start to get into the 'trusted'/'non-trusted'
> application area..]

Fortunately, no one would ever think of removing that query from the worm
or circumventing the mechanism in the OS, so that it copies itself without 
notice in the future.  ;-\

Cheers,

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

[SC-L] Application Insecurity --- Who is at Fault?

[Kenneth R. van Wyk]

Greetings++,

Another interesting article this morning, this time from eSecurityPlanet.  
(Full disclosure: I'm one of their columnists.)  The article, by Melissa 
Bleasdale and available at 
http://www.esecurityplanet.com/trends/article.php/3495431, is on the general 
state of application security in today's market.  Not a whole lot of new 
material there for SC-L readers, but it's still nice to see the software 
security message getting out to more and more people.

Cheers,

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

[SC-L] Mobile phone OS security changing?

[Kenneth R. van Wyk]

Greetings,

I noticed an interesting "article" about a mobile phone virus affecting 
Symbian-based phones out on Slashdot today.  It's an interesting read:

http://it.slashdot.org/it/05/04/06/0049209.shtml?tid=220&tid=100&tid=193&tid=137

What particularly caught my attention was the sentence, "Will mobile OS 
companies, like desktop OS makers, have to start an automatic update system, 
or will the OS creators have to start making their software secure?"  Apart 
from the author implying that this is an "or" situation, it's something that 
many of us have been saying for a very long time.  (See my/Mark Graff's 
related op-ed from over a year ago at: 
http://www.securecoding.org/authors/oped/feb132004.php)

Cheers,

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

[SC-L] Microsoft paper on their Security Development Lifecycle (SDL)

[Kenneth R. van Wyk]

FYI, Steve Lipner and Michael Howard have put out a paper describing 
Microsoft's Security Development Lifecycle (SDL).  The full paper can be 
found at: 
http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnsecure/html/sdl.asp

You can find the abstract below as well.  Enjoy.

Cheers,

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


Abstract: This paper discusses the Trustworthy Computing Security Development 
Lifecycle (or SDL), a process that Microsoft has adopted for the development 
of software that needs to withstand malicious attack. The process encompasses 
the addition of a series of security-focused activities and deliverables to 
each of the phases of Microsoft's software development process. These 
activities and deliverables include the development of threat models during 
software design, the use of static analysis code-scanning tools during 
implementation, and the conduct of code reviews and security testing during a 
focused "security push". Before software subject to the SDL can be released, 
it must undergo a Final Security Review by a team independent from its 
development group. When compared to software that has not been subject to the 
SDL, software that has undergone the SDL has experienced a significantly 
reduced rate of external discovery of security vulnerabilities. This paper 
describes the SDL and discusses experience with its implementation across 
Microsoft software. (19 printed pages)

[SC-L] PHP Consortium Tackles Third-Party Application Security

[Kenneth R. van Wyk]

I know that PHP is often the whipping boy of programming languages, at least 
from the perspective of Software Security--and with good reason.  To address 
the situation, a PHP Security Consortium has been launched.  There's an 
eWEEK.com article on the topic available at: 
http://www.eweek.com/article2/0,1759,1758408,00.asp

Among other things, the group, "plans to promote secure programming practices 
among developers and set up a one-stop shop for documentation, tools and 
standards."  Sounds to me like a step in the right direction, at least.

Anyone here involved in that effort?  Any comments/opinions?

Cheers,

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

Re: [SC-L] ZDNnet: Securing data from the threat within [by buying products]

[Kenneth R. van Wyk]

On Monday 17 January 2005 14:55, Crispin Cowan wrote:
> I participated in a workshop on on insider attacks several years ago. We
> identified 2 kinds of insider attacks:

(Was this Mike Skroh's (DARPA) workshop out at RAND?  If so, I also 
participated in this.  In fact, it's where I met you, Crispin.  You demo'd 
VMware on your laptop for me and made me a VMware believer...:-)

> * authorized users: [snip...]
> * non-authorized users: [snip...]

Agreed.

> So we agree that more secure systems such as RBAC and Immunix do help to
> address the problem of insider attackers. What they don't do is address
> the problem of authorized insiders abusing their authority. That is
> where this new class of products comes in: they track the movement of
> sensitive organizational data by /content/ rather than by access
> control, and complain when content crosses a barrier that it should not.

Understood, and at least much of this new class of products is based on 
statistical analysis of event logs.  Certainly, products simplify that 
scenario, but it can also be done without add-on products.

> But as I wrote before, such products, especially network-based products,
> will fail to detect an authorized user accessing data and then dumping
> it to CDR or USP memory stick and walking it out of the building in
> their underwear.

There is also a new class of products that do access control and logging at 
the PC client level, so that things like USB stick access can be (nominally) 
controlled and logged, FWIW.  I'll bet that a determined, authorized 
adversary can find ways of circumventing, though...

> Because the end-game of covert channel prevention always leads to an
> anal cavity search :)

ACKand ick!

So, where's the Software Security lesson in all of this?  IMHO, it's to ensure 
adequate application-level event logging and data access control 
capabilities.

Cheers,

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

Re: [SC-L] ZDNnet: Securing data from the threat within [by buying products]

[Kenneth R. van Wyk]

Crispin Cowan wrote:
I completely disagree. I find the article to be timely and informative.
What Kenneth suggests (use of RBAC) will not solve the problem. First 
of all, RBAC is not practical to deploy in most situations; companies 
are still trying to cope with AV and firewalls, and just beginning to 
think about host and application security. RBAC is completely beyond 
them.
Well, my main objection to the article was its advocacy for addressing 
the insider threat problem simply by buying security products.  I 
brought up RBAC simply as one example that people may consider as they 
seek solutions. 

Whether it be role-based, or a plain old-fashioned, group/ACL sort of 
access control, coupled with good event logging and monitoring, I think 
that most sites would be better served by exploring the access control 
mechanisms that they currently have instead of just buying more security 
products.  That's not to say that there aren't products that may be 
highly useful, but it is to say that the solutions should start with 
well designed and implemented access  control and logging.  I stand by 
that opinion.

Cheers,
Ken van Wyk

[SC-L] ZDNnet: Securing data from the threat within [by buying products]

[Kenneth R. van Wyk]

Greetings all,

I saw a moderately interesting article this morning on ZDNet (see 
http://news.zdnet.com/2100-1009_22-5520016.html?tag=zdfd.newsfeed for the 
full text).  The premise of the article is about how companies have been 
building external perimeters for years and now they need to also protect 
themselves from insiders, because, "...now discontented, reckless and greedy 
employees, and disgruntled former workers, can all be bigger threats than the 
mysterious hacker."

The article goes on to list some new products, technologies, and methods for 
protecting data from the insiders.  It says, "a whole new class of products 
has sprung up aimed at keeping employees and other insiders from sending 
confidential information outside the company."  It describes network-level 
products as well as the need for client-level products for monitoring and 
controlling data flow.

IMHO, what's missing here is a discussion on writing better enterprise 
applications that make effective use of concepts like role-based access 
control, transaction/event logging and monitoring, etc.  In fact, the article 
would lead an IT security manager to think that the only solution to insider 
problems is to buy more security products.  Frustrating...

To find a fairly "mainstream" article like this that is (again, IMHO) so 
thoroughly off base really makes me wonder whether the Software Security 
community is making progress or not.  Opinions?

Cheers,

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

[SC-L] eWeek articles on Software Security

[Kenneth R. van Wyk]

FYI, there's a couple interesting Software Security related articles today 
over on eWeek (see http://www.eweek.com/article2/0,1759,1743951,00.asp).

The main article, "Tools Block Code Busting Crooks" describes several 
developments in the source code analysis space, including Ounce Labs' "Secure 
Foundations Initiative, a program that puts the source code vulnerability 
analysis software vendor in collaboration with universities to train 
developers in secure software."

You might also want to check out the related links on the same page for other 
news in the Software Security world.

Cheers,

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

[SC-L] Administrivia: Thanks for the input and happy holidays

[Kenneth R. van Wyk]

Hi all,

First, thanks to everyone that took the time to send me a response to my 
recent questions about the mailing list.  To summarize the vast majority of 
your responses to me:

- You find the group useful, keep running it.
- You appreciate the substantive discussions and debates on software security 
issues.
- You dislike the "my language/OS is better than yours" debates.
- You're sometimes concerned by the lack of traffic here.

Ok, so no real surprises there, but I do appreciate each and every response 
that I got.

The solstice-time holidays are nearly upon us.  Over the next couple of weeks, 
I'll be moderating any list traffic that comes in approximately once a day, 
from various webmail, PDA, and kmail systems that I'll be on.  If your 
posting doesn't show up immediately, please be patient.

Happy and safe holidays to all!

Cheers,

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

[SC-L] On SC-L's first anniversary

[Kenneth R. van Wyk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings SC-L folks,

This week marks SC-L's first anniversary.  Thanks to all that have
participated over the year.  And special thanks to those that have helped
behind the scenes -- Sean, Mark, and the good folks at Nidhog.com for hosting
(and putting up with) all of my sites.  For those interested in stats, we
have hovered right around 700 members (between the SC-L and SC-L-DIGEST
groups) pretty consistently for about the past 10 months.  (I have no way of
counting the readers that grab the archives and/or the RSS feed.)

The group has been active at times and pretty close to dormant at other times.
So much so that I often ask myself if maintaining the group is worth the
effort, quite candidly.  I've always seen my role here as the facilitator,
first and foremost, although at times, I forward articles and URLs that I
believe will be of interest to the group.  (Are these useful?)

In any case, as the list's sole sponsor and moderator, I have a couple
questions that I'd like to solicit the group's feedback on.  Responses,
either privately to me or publicly to the entire group are most appreciated.
Constructive criticism is always welcome, of course.  Flames and whines, as
always, can go straight to /dev/null.  ;-)

- - What do you find to be the most useful about the group?

- - What do you find least useful?

- - What improvements would you suggest?

- - Would you be willing to contribute your own time and effort in implementing
your suggestion(s) above?

Cheers,

Ken van Wyk
- --
KRvW Associates, LLC
http://www.KRvW.com
(See above URL for PGP key)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBo09eTPjPRMxm0KoRAleQAJ91HeTtbvbsM4Y+gPmo7uCChbEKbwCfeR/K
6myfTm89TcvFD0VMuYKZMVA=
=Jm3S
-END PGP SIGNATURE-

[SC-L] eSecurityPlanet article on Fortify source code scanner

[Kenneth R. van Wyk]

FYI, interesting article on eSecurityPlanet regarding Fortify's commercial 
source code scanning tool -- see the full text at 
http://www.esecurityplanet.com/patches/article.php/3439021

Among other things, the article says, "In addition to new language support for 
C# -- the software already supports C, C++, PL/SQL, Java Server Pages (JSP) 
and Java -- Fortify has added four new analyzers, a rules manager and an 
audit manager to prioritize the level of software flaws."

Cheers,

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

Re: [SC-L] How do we improve s/w developer awareness?

[Kenneth R. van Wyk]

<[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Secured by aspStation
Sender: [EMAIL PROTECTED]
Precedence: bulk
Mailing-List: contact <[EMAIL PROTECTED]> ; run by MajorDomo
List-Id: Secure Coding Mailing List 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
List-Help: 
List-Archive: 
Delivered-To: mailing list [EMAIL PROTECTED]
Delivered-To: moderator for [EMAIL PROTECTED]

Dana Epp wrote:

> I think we have to go one step further.
>
> Its nice to know what the attack patterns are. A better thing to do is
> to know how to identify them during threat modeling, and then apply
> safeguards to mitigate the risk. ie: We need a merge of thoughts from
> "Exploiting Software" and "Building Secure Software" into a single
> source... where attack and defense can be spoken about together.

I fully agree with you, Dana, and it's a good point.  That said, though,
let me just revisit the observation that I made at the beginning of this
thread.  In my discussions with a _whole bunch_* of developers, I've
noted that few of them even bother to notice security faults in software
beyond the most cursory levels.  (*No, this doesn't represent a
statistical sampling or any scientific study of any sorts; just my gut
feel.)  The observation came from noticing how few developers read, or
are even aware of the existance of things like Full-Disclosure, Bugtraq,
PHRACK, and RISKS.

Gunnar Peterson noted that security is just one among many "*-ilities"
that developers have to contend with, and that makes good sense to me.

So, I guess that the real question should be, "how do we get software
developers _in general_ to sit up and notice software security?"
Training, books, etc., are well and good, but they presuppose that the
developer has already passed the first hurdle of noticing that security
is an issue.  I'm convinced that most developers will quickly understand
at least most of the issues once they start reading/learning.

Cheers,

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

[SC-L] How do we improve s/w developer awareness?

[Kenneth R. van Wyk]

Greetings,

In my business travels, I spend quite a bit of time talking with Software 
Developers as well as IT Security folks.  One significant different that I've 
found is that the IT Security folks, by and large, tend to pay a lot of 
attention to software vulnerability and attack information while most of the 
Dev folks that I talk to are blissfully unaware of the likes of 
Full-Disclosure, Bugtraq, PHRACK, etc.  I haven't collected any real stats, 
but it seems to me to be at least a 90/10% and 10/90% difference.  (Yes, I 
know that this is a gross generalization and there are no doubt significant 
exceptions, but...)

I believe that this presents a significant hurdle to getting Dev folks to care 
about Software Security issues.  Books like Gary McGraw's Exploiting Software 
do a great job at explaining how software can be broken, which is a great 
first step, but it's only a first step.

Am I alone in this opinion or have others noticed the same sort of thing?  
It's going to be a long, slow battle, in my opinion.

Cheers,

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

[SC-L] Programming Legends Debate .Net, J2EE

[Kenneth R. van Wyk]

Hi All,

FYI, interesting article over at eweek -- 
http://www.eweek.com/article2/0,1759,1699480,00.asp -- about a debate this 
past week at OOPSLA on the merits of a few of today's OO languages.  The 
eWeek article describes it as follows, "At a session entitled "The Great J2EE 
vs. Microsoft .Net Shootout" at the Object-Oriented Programming, Systems, 
Languages, and Applications (OOPSLA) conference here this week, software 
development superstars such as Anders Hejlsberg, Microsoft Corp. 
distinguished engineer and lead designer for the C# language; John Crupi, 
chief Java architect for Sun Services at Sun Microsystems Inc.; Don Box, 
leading Microsoft architect on its Indigo project; Rob High, IBM's chief 
architect for the WebSphere Application Server Family; and Alan Knight, lead 
developer for the Web Toolkit at Cincom Systems Inc. and a Smalltalk expert."

It was interesting to me because the word security was hardly mentioned, at 
least in the column, and when it was it was really on with regards to web 
services security.

Cheers,

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

Re: [SC-L] Open Source failure analysis tool released for Linux

[Kenneth R. van Wyk]

ljknews wrote:
At 8:23 AM -0400 10/15/04, Kenneth R. van Wyk wrote:
I believe that we don't do enough to analyze and learn from software failures.  
I believe the industry as a whole does plenty to analyze software
failures, particularly considering how little is done to avoid
those errors.  Added analysis in the face of near-zero remediation
would be useless.
How many times do we see "buffer overflow" as the cause, yet even on
this mailing list people still defend the use of languages that not
only permit but actually promote such errors.
Well, I did say "...analyze AND learn...".  :-)
Seriously, though, there's plenty of data on the symptoms of failures -- 
advisories, securitytracker.com, etc., but not enough on the causes in 
my opinion.

And, to exacerbate the problems, in every software security tutorial 
that I do, I ask the students how many of them read information from 
places like bugtraq, full-disclosure, phrack, and such.  Among the 
software developers, _maybe_ 5% of them say that they do.  Admittedly, 
the percentage is better among the IT Security folks that I talk to, but 
they're not generally the ones that are writing the software.  Of 
course, that's not a scientific survey or anything, but I sure get the 
feeling that very few software dev folks spend any/much time analyzing 
failures.

Cheers,
Ken

[SC-L] Open Source failure analysis tool released for Linux

[Kenneth R. van Wyk]

Greetings,

Saw an announcement today on DesktopLinux.com (see 
http://www.desktoplinux.com/news/NS6923692411.html for the full scoop) about 
an open source tool to analyze software failures on (IA-32) Linux systems.  
Although not specifically security-related, the vendor claims that the tool 
will help improve software reliability.

I believe that we don't do enough to analyze and learn from software failures.  
Look at how other engineering disciplines analyze their failures and then 
learn from them -- bridge collapses, airplane crashes, etc., all come to 
mind.  Even the vulnerability advisories that we get from vendors, CERT, 
etc., don't typically focus on the root cause (no pun intended), but the 
solution set.  That's fine for the people that run computers, but not for the 
people that write the software.

Cheers,

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

[SC-L] Bug 259708: A human perspective

[Kenneth R. van Wyk]

Greetings all,

I saw an interesting story today, by way of a Slashdot link 
(http://science.slashdot.org/article.pl?sid=04/10/06/1845236&tid=191&tid=134&tid=14), 
about a developer's persepective in reporting a vulnerability in Mozilla. The 
full story can be found here: 
http://weblogs.mozillazine.org/weirdal/archives/human259708.html

It's interesting to read the author's perspective, as he's a software 
developer and has never been a "security guy" per se.  The Slashdot article 
also talks about how well the FLOSS bug process worked.  Enjoy...

Cheers,

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

[SC-L] eWeek: App Developers Need to Redouble Security Efforts

[Kenneth R. van Wyk]

FYI, there's an interesting article in eWeek today -- see 
http://www.eweek.com/article2/0,1759,1663716,00.asp -- regarding a recent 
Gartner study on software security.  Among other things, it says, "Gartner 
predicts that if 50 percent of software vulnerabilities were removed prior to 
production use for purchased and internally developed software, enterprise 
configuration management costs and incident response costs each would be 
reduced by 75 percent. "  Enjoy...

Cheers,

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

[SC-L] Design flaw in Lexar JumpDrive

[Kenneth R. van Wyk]

Greetings SC-L folks.  Wow, it's been absurdly quiet here lately, and not just 
because I've been out of the office on travel so much.  Perhaps we've reached 
an end of Software Security topics to discuss?  ;-)

In any case, I thought that I'd try to seed things a bit with this...

I know that this isn't exactly _news_, as it's a couple weeks old now, but 
it's interesting nonetheless.  A recent @Stake advisory 
(http://www.atstake.com/research/advisories/2004/a091304-1.txt) detailed a 
vulnerability in Lexar's JumpDrive USB drive.

According to the @Stake advisory, even though the device is able to encrypt 
user data using 256-bit AES encryption, "The password can be observed in 
memory or read directly from the device, without evidence of tampering."  
That strikes me as a pretty glaring example of a _really bad mistake_ made in 
designing the crypto system.

Certainly not the first -- or, I'm sure the last -- time that we've seen 
mistakes like this.  It seems to me, though, that a good threat modeling 
exercise should have prevented this from being introduced into the product in 
the first place.  Or, do you think that the developers knew of the problem, 
but the pressures of product marketing overwhelmed sound design practices?  
It's a rhetorical question, obviously, since I can't imagine anyone from the 
design team speaking up publicly, but it sure would be interesting to know...

Cheers,

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

[SC-L] ComputerWorld interview with Theo de Raadt on Software Security

[Kenneth R. van Wyk]

FYI, ComputerWorld is running an interesting interview with Theo de Raadt, on 
the state of software security, and OpenBSD in particular.  See 
http://www.computerworld.com.au/index.php/id;1498222899;fp;16;fpid;0 for the 
complete text.

Cheers,

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

[SC-L] Government Computer News (GCN) -- Contract addendum could enforce software security

[Kenneth R. van Wyk]

Another FYI today...  I saw an interesting article in GCN (via a link from 
LinuxSecurity.com) regarding an announcement from the folks at Ounce Labs.  
The article (which is at http://www.gcn.com/23_26/product-briefs/27167-1.html 
for those interested) states, "Ounce Labs has published sample contract 
language for software development that sets specific security standards and 
requires a security audit of the source code. The language frees the buyer 
from having to pay for software that does not meet the standards."

Anyone here familiar with any organizations that have adopted Ounce Labs' 
contract verbiage -- or something conceptually similar to it?

Cheers,

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

[SC-L] eSecurityPlanet column on Software Security

[Kenneth R. van Wyk]

Greetings all,

Wow, it sure has been quiet here for a couple weeks.  Perhaps it's just those 
late summer (or winter, for you southern hemispherians) vacations...

In any event, just an FYI here.  My September eSecurityPlanet column hit the 
streets today (see http://www.esecurityplanet.com/views/article.php/3404191) 
if you're interested.  It's on the topic of Software Security.  I should 
point out that it's primarily written for an IT Security audience.  It's slow 
progress convincing them that Software Security is more than running a pen 
test against an application a week before it goes live in the data center...

Cheers,

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

Re: [SC-L] Grass roots secure coding efforts

[Kenneth R. van Wyk]

Hans Westphal wrote:
Other suggestions:
Subscribe to Security lists:
[EMAIL PROTECTED], [EMAIL PROTECTED]
Self Education through books 
...
and Webcast's
...
Thanks Hans -- good suggestions.  I think, though, that what most of my 
students have wanted more than "just" information sources are 
suggestions of tangible things that they can start _doing_ in their 
journey to really practicing secure coding.  For example, although most 
of them agree that a threat modeling process (a la STRIDE/DREAD) makes 
sense for the long run, it's too much to expect them to undertake right 
away (for all the reasons that I listed previously in this thread). 

So, the basic premise in the brainstorming that we went through in the 
classes has been to answer the question, "What tangible actions can they 
start taking immediately that will be both helpful and feasible to 
implement within existing budget/time constraints?"  They jumped right 
on ideas like adding an information sharing portal/fileshare where they 
can share experiences, vetted designs, architectures, etc.  That's a low 
cost, low risk thing that is easy to accomplish.  (It remains to be seen 
if they actually make use of it, but that's another issue.)

That said, I like including a list of useful lists, sites, e-zines, 
etc., that they can dive into to further their knowledge.  (It amazes me 
how few of the software developers I've spoken with have ever even heard 
of Full-Disclosure, PHRACK, etc.)

Cheers,
Ken van Wyk
http://www.KRvW.com

[SC-L] Grass roots secure coding efforts

[Kenneth R. van Wyk]

Greetings all,

One of the things that I hear most from software developers when I deliver 
secure coding tutorials and such is that they're likely to be unable to do 
things like detailed threat modeling, risk analyses, etc.  The reason most 
often cited is that they're under tight deadlines and there's not enough time 
in the schedule for such activities.  

Of course, to really expect any sort of culture shift, there would need to be 
top-level support for adopting secure coding practices.  That said, I often 
spend some time brainstorming lists of things that the students can consider 
trying by themselves as soon as they are back in their offices.  I'm talking 
about "grass roots" sorts of activities that won't break the bank (or 
schedule) here.

Some of the things that the students have suggested include the following:

- Informal peer review of code modules
- Incorporation of (usually free) static code review tools in the code reviews
- Setting up an information sharing site/portal/drive internally for 
developers to load useful links, tools, experiences, etc.
- and so on

Most often, the students agree that these sorts of things are the types of 
simple first steps that they could reasonably expect to take.  Anyone here 
have other suggestions on other first steps that developers might consider, 
even in the absence of top-level embracing of a more secure development 
methodology?

(No, I'm not suggesting that a simple list like this be any sort of substitute 
for a more in-depth program, but it's a starting point for developers to 
experiment with in trying to improve the security of their software dev 
practices.)

Cheers,

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

[SC-L] Book review - Threat Modeling

[Kenneth R. van Wyk]

Hi all,

While doing a bit of daily reading today, I found a review of  Frank 
Swiderski's "Threat Modeling" book at Dana Epp's blog site (see 
http://silverstr.ufies.org/blog/archives/000661.html).  With gracious 
permission to repost from Dana, below is the text of the book review.

Cheers,

Ken van Wyk
http://www.KRvW.com

=

August 03, 2004

Book Review - Threat Modeling
by Dana Epp, http://silverstr.ufies.org/blog/

I finished reading Threat Modeling last week but just haven't had time to blog 
a review about it until now. 

I first learned of Frank Swiderski when he worked at @stake, meeting him in 
passing at a convention. When I heard he was working for Microsoft as an 
application security specialist I wasn't to sure what was going on.

Then he released a pretty good threat modeling tool (check out his Channel9 
interview on the subject) and I started to put it together.

Out of no where, announcements of his new book on threat modeling were abound. 
I dug deep trying to find it, only to learn it wasn't actually released. I 
waved my money at Amazon, but they just wouldn't take it until the pre-order.

Long story short, I finally got it. And it was well worth the wait.

If I could sum up the book in a single sentence it would be something like, 
"Frank tool the ball from Michael in Writing Secure Code (WSC) and ran with 
it to the goal line." This book picks up where Michael left off, and 
completes the picture of threat modeling in greater depth. But you would have 
to expect that. The threat modeling process is evolving at Microsoft and the 
snap shot we see in this book is knowledge improved upon since the release of 
WSC. Actually, you will notice a big difference between v1 and v2 of WSC, and 
this step was logical in the new book.

With that said, an abridged table of contents can show how this was broken 
down:

Introduction to Application Security
Why Threat Modeling
How an Adversary Sees an Application
Constraining and Modeling the Application
The Threat Profile
Choosing What to Model
Testing Based on a Threat Model
Making Threat Modeling Work
Sample Threat Models

Now that I read that TOC, it doesn't do the book justice. Let me see if I can 
provide some highlights of the book.

First off, one thing I really liked was the fact that almost HALF the book is 
dedicated to actual sample threat models, showing practical applications 
approached differently. Throughout the book three examples were used:

Fabrikam Phone 1.0 - A phone system 
 
Humongous Insurance Price Quote Website - A simpe web application
 
A. Datum Corporation Access Control API - A software library
These three examples were interesting as it showed different approaches to 
threat modeling, in three different areas. These examples really hit home for 
me, and brought concepts together quite nicely.

An area which I enjoyed was looking at how an advesary would approach the 
system. Now, this isn't like how Gary did it in Exploiting Software: How to 
Break Code. In a simplistic overview, Frank presents it like:
 
An advesary's view is based on entry points of the system, which when entered 
get you access to assets, based on what trust level you appear to have. An 
application can not be attacked unless an adversary has a way to interact 
with it, and an asset of interest must exist for that to occur. In other 
words, a threat cannot exist unless there is an asset that interests the 
advesary.

You can explore how this comes about by properly modeling the system with the 
use of data flow diagrams (DFD). I really enjoyed this part, as I never 
properly understood how to graphically depict this. With this new knowledge I 
will make better use of the visio component in the threat modeling tool Frank 
released. 

Quite frankly I found a lot of things approached different in the book. In my 
office our use of threat modeling has been to create a Threat Profile by 
classifying threats against STRIDE effects for each part of the system, and 
then map attack trees on how to exploit that. When complete we would then use 
the standard infosec risk formula of...

risk = Probability(chance) * Damage Potential (damage)
... to prioritize the risks and they reduce it with mitigation techniques.

This book showed me a lot of new ways to approach threat modeling. We were 
only doing a fraction of what really COULD be done in threat moding. From 
data flow diagrams to DREAD analysis, the book shows how to properly do an 
end to end threat model.

Would I recommend this book? Absolutely. Do I have any complaints? Only that I 
now want to go back and redo our threat models in greater depth. I have to 
make time for this... crucial time I don't really have. Of course, the book 
even covers that off, and helps to show how in a time crunch, how to 
prioritize things to get the most in the least amount of time.

I arrogantly believed I knew everything there was "needed to be known" about 
threat modeling to use it in a real world en

[SC-L] Programming languages -- the "third rail" of secure coding

[Kenneth R. van Wyk]

Greetings,

It appears as though we may well have discovered software security's third 
rail over the last couple of weeks in the discussions regarding programming 
language choices.  I don't mean to fan those flames by any means, trust me.  
However, I noticed several announcements for PHP version 5 (see 
http://www.zend.com/ for the official announcement and press release) over 
the weekend.  PHP has long been the whipping boy of secure programming, and 
version 5 appears to add a great deal of new functionality to this popular 
language.  Secure or not, there's a lot of PHP users and coders out there, 
and this added complexity certainly enhances its "trinity of trouble" profile 
(with respect to Gary McGraw's "Exploiting Software").

Along those lines, there's a good article at 
http://otn.oracle.com/pub/articles/hull_asp.html that compares PHP5 against 
ASP.NET, including the security features of each.

Happy reading...

Cheers,

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

Re: [SC-L] Protecting users from their own actions

[Kenneth R. van Wyk]

Wall, Kevin wrote:
Isn't this something that users probably shouldn't be given a choice
on? Normally I would think that corporate security policy dictate
keeping the AV software / signatures up-to-date as well as dictating
the (personal) firewall configurations. Some centrally administered
software should do these things...
I agree that central administration works best in today's corporate 
environments, but I was referring also to the more general desktop 
environments as well, right down to the home and SOHO users that 
have to install and/or update their own.

Aside from that issue, though, the primary point that I wanted to get 
across is that there are substantial limitations to what we can 
accomplish through user education.  I believe that our 
software -- from enterprise app servers through desktop emailers 
and browsers -- needs to do better at protecting users, even 
when they make decisions that we would think to be unwise.

Cheers,
Ken van Wyk

[SC-L] Protecting users from their own actions

[Kenneth R. van Wyk]

Hi All,

FYI...  This topic has come up here a few times, so I thought that I'd send a 
pointer to my July eSecurityPlanet column 
(http://www.esecurityplanet.com/views/article.php/3377201 - free, no registration 
required).  In the column, I take the seemingly unpopular view --at least in 
this group -- that we can't count on things like user awareness training to 
prevent users from doing things like clicking on unsafe email attachments.  I
also make a plug for better software security across the industry.

Cheers,

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

Re: [SC-L] ACM Queue article and security education

[Kenneth R. van Wyk]

James Walden wrote:
I'd like to open a discussion based on this quote from Marcus Ranum's 
ACM Queue article entitled "Security: The root of the problem":
Thanks.  I also read Marcus's article with interest.  Caveat: clearly, I 
have a biased outlook, since software security training is one of the 
things that I do for a living.

Overall, I like and agree with much of what Marcus said in the article.  
I don't, however, believe that we can count on completely putting 
security "below the radar" for developers.  Having strong languages, 
compilers, and run-time environments that actively look out for and 
prevent common problems like buffer overruns are worthy goals, to be 
sure, but counting solely on them presumes that there are no security 
problems at the design, integration, or operations stages of the 
lifecycle.  Even if the run-time environment that Marcus advocates is 
_perfect_ in its protection, these other issues are still problematic 
and require the developers and operations staff to understand the problems.

From my perspective, security education is only beginning to climb an 
initial upward curve.  While classes in security topics are becoming 
more common in undergraduate computer science course catalogs, their 
presence is far from universal.  I don't know of any university that 
requires such a class for an undergraduate CS degree; if any such 
programs exist, they're not common.
I agree with you on this, certainly.  My nephew is a senior in an 
undergrad CS curriculum and his university has yet to discuss security 
in any of his course work, to my knowledge. 

While there are non-university classes and workshops that teach 
software security, I doubt that a majority of developers have attended 
even one such class.  Software security has to be integrated into the 
CS curriculum before we can expect a majority of developers to have 
the appropriate skills, and then there will still be the issue of 
applying them under deadline pressure.
Yup, but in the "belt and suspenders" approach that I like to advocate, 
I'd like to see software security in our undergrad curricula as well as 
professional training that helps developers understand the security 
touch points throughout the development process -- not just during the 
implementation phase.

Cheers,
Ken van Wyk
http://www.KRvW.com

[SC-L] ACM Queue - Content

[Kenneth R. van Wyk]

FYI, there's an ACM Queue issue out that focuses on security -- see 
http://acmqueue.com/modules.php?name=Content&pa=list_pages_issues&issue_id=14

Two articles there that should be of interest to SC-L readers include Marcus 
Ranum's "Security: The root of the problem -- Why is it we can't seem to 
produce secure, high quality code?" and Philip Laplante's "First, Do No Harm: 
A Hippocratic Oath for Software Developers".  Enjoy...

Cheers,

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

[SC-L] SPI, Ounce Labs Target Poorly Written Code

[Kenneth R. van Wyk]

FYI, a couple of announcements from SPI Dynamics and Ounce Labs hit eWeek.com 
today -- see http://www.eweek.com/article2/0,1759,1617901,00.asp for the full 
text.

According to the article, SPI Dynamics has released its "SecureObjects" 
product, which is a series of (presumably) securely written objects that 
developers can make use of for performing various security-related tasks 
(e.g., input validation) in their code.  The article quotes SPI Dynamics' CTO 
as saying, "It doesn't require developers to learn about security," which 
strikes me as being a rather bold statement.

Meanwhile, Ounce Labs has put out a new version of its Prexis source code 
scanner.   It currently scans C and C++, but the article says that a Java 
version will be available in July.

Reports of user experiences with these tools would be appreciated here.

Cheers,

Ken

P.S. Anyone interested in seeing a bit of Budapest can check out some of the 
shots I took while I was there at http://www.vanwyk.org/ken/galleries.php

-- 
KRvW Associates, LLC
http://www.KRvW.com

[SC-L] Administrivia: Moderator is back

[Kenneth R. van Wyk]

Hi all,

Back from a few days in Budapest at the annual FIRST conference (see 
http://www.first.org if you're interested).

FYI -- I did my best to keep the submissions flowing while I was away, but my 
only tools were a Sony Clie UX50 PDA over GPRS/GSM via Bluetooth to my 
Ericsson T39m GSM phone.   It was the first time that I tried to do my list 
moderating via a PDA.  It didn't work perfectly, as I see a couple of 
submissions got munged (feel free to re-submit anything that didn't go out 
cleanly, with my apologies), but for the most part it worked pretty well.  

It sure was an interesting/exhilerating/strange feeling to be able to 
send/receive email while buzzing across the Hungarian, Austrian, and German 
countryside in a train.

Anyway, it's good to be back.  My basset hounds sure appreciate it, anyway.  
Other than the usual spam that the list received, the submission queue is 
looking pretty empty.  Feel free to change that.

Cheers,

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

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[Kenneth R. van Wyk]

der Mouse wrote:
All that a "better" language will bring you in this regard is that it
will (a) push the sloppiness into places the compiler can't check and
(b) change the ways things break when confronted with input beyond the
design underlying their code.
Although I am in favor of languages that help prevent such nasties as 
input buffer overruns, this is an excellent point.  A sloppy programmer 
will write sloppy code.  Reminds me of an old saying that I heard years 
ago while studying mechanical engineering: a determined programmer can 
write a FORTRAN program in ANY language.  :-)  (Well, notwithstanding 
FORTRAN's built-in ability of handling complex numbers, but I digress...)

IMHO, the bottom line is that there's no excuse for sloppiness and a 
strong language can only do so much to prevent the programmer from 
his/her own sloppiness.

Cheers,
Ken van Wyk
http://www.KRvW.com

[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

[SC-L] More host-based production security tools unveiled

[Kenneth R. van Wyk]

Greetings all,

In this (http://www.eweek.com/article2/0,1759,1607680,00.asp) article over on 
eWeek.com, a couple of new tools are described, including Determina's 
SecureCore and Immunix's Application Firewalling Suite.  The article states, 
"This tack represents a shift from the decades-old approach of detecting and 
stopping attacks in progress using signatures or pattern-recognition 
algorithms. Customers and security experts say the new tools signal a new 
direction for the industry at large."

As a staunch non-advocate of the patch-and-chase game, I find this encouraging 
and sincerely hope that the tools live up to the expectations that are being 
set.  I also wonder if things such as AMD's relatively new NX (non-execute) 
bit architecture can be of any value in preventing things like buffer 
overflow attacks in production environments.  While they're no substitute for 
designing and coding things properly in the first place, I do like the notion 
of the system preventing such attacks before they can do harm.  (In fact, 
this concept is very much at the center of my first monthly column on 
eSecurityPlanet, which should be hitting http://www.eSecurityPlanet.com later 
today.)

Although the Immunix suite was briefly described here earlier, the Determina 
product wasn't.  Has anyone here looked at these tools and care to share 
their experience with either or both?

Cheers,

Ken van Wyk

-- 
KRvW Associates, LLC
http://www.KRvW.com

[SC-L] Interesting article on minimizing privileges

[Kenneth R. van Wyk]

Anyone looking for a great introduction to putting the principle of least 
privilege into action, check out David Wheeler's article at:

http://www-106.ibm.com/developerworks/linux/library/l-sppriv.html?ca=dgr-lnxw04Privileges

It cites one of my favorite examples of least privilege, Wietse Venema's 
Postfix program.  Great stuff, check it out.

Cheers,

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

[SC-L] Microsoft threat modeling tool available for free

[Kenneth R. van Wyk]

Greetings,

Almost missed this one while I was out of the office for a couple days...  
Microsoft have announced the free availability of a threat modeling tool by 
Frank Swiderski, who is also writing a soon-to-be released book on threat 
modeling.  Details on the tool (warning: requires .NET framework to be 
installed) as well as the book are available at:

http://www.microsoft.com/downloads/details.aspx?FamilyID=62830f95-0e61-4f87-88a6-e7c663444ac1&displaylang=en

Has anyone here tested the tool yet?  Opinions?  I'm a firm believer that not 
enough effort is paid to the threat analysis process during the design phase, 
so any tool that makes that easier should be a good thing -- even if it 
doesn't run on my Debian/Sarge desktop system.  :-)

Cheers,

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

[SC-L] LinuxWorld | Secure coding attracts interest, investment

[Kenneth R. van Wyk]

Greetings all,

FYI, it looks like we're at the beginning of a new wave of software security 
tools.  There's a few commercial products beginning to hit the market that 
take static src code scanning to a new level.  See the link below for a 
LinuxWorld article that briefly (!) describes @stake's new SmartRisk Analyzer 
tool in addition to Fortify's Source Code Analysis suite.  These appear to 
pick up where current static analysis tools (e.g., ITS4, Flawfinder) leave 
off.

Anyone here willing/able to share some _user_ level experiences with any of 
these tools?  It'll be interesting to hear how they hold up in real software 
development environments.

http://www.linuxworld.com.au/nindex.php/id;1780700095;fp;2;fpid;1

Cheers,

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

[SC-L] Andy Tanenbaum on Linux's origins and security

[Kenneth R. van Wyk]

Andy Tanenbaum, the author of the MINIX operating system, recently posted an 
opinion piece on the origins of Linux.  It's a fascinating albeit somewhat 
lengthy read -- see http://www.cs.vu.nl/~ast/brown/ for the full text.  

At the very end of the document, he talks about the security of a microkernel 
system like (his own) MINIX vs. that of a monolithic kernel like Linux.  He 
writes, "With all the security problems Windows has now, it is increasingly 
obvious to everyone that tiny microkernels, like that of MINIX, are a better 
base for operating systems than huge monolithic systems. Linux has been the 
victim of fewer attacks than Windows because (1) it actually is more secure, 
but also (2) most attackers think hitting Windows offers a bigger bang for 
the buck so Windows simply gets attacked more. As I did 20 years ago, I still 
fervently believe that the only way to make software secure, reliable, and 
fast is to make it small. Fight Features."

Cheers,

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

[SC-L] InformationWeek: Executives Complain About Software Vulnerability To Hackers

[Kenneth R. van Wyk]

FYI, interesting article today in Information Week regarding a trade group of 
senior executives complaining about vulnerable software:

http://www.informationweek.com/story/showArticle.jhtml?articleID=20800071

Among other things, the article quotes the group's security task force leader, 
Marian Hopkins, "We would challenge the software industry to create products 
that are easier to use, where security is a default component of the 
software".

Cheers,

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

[SC-L] Clarke: Hold Developers Accountable for Software Insecurity

[Kenneth R. van Wyk]

FYI, eWeek is running an article (see 
http://www.eweek.com/article2/0,1759,1592964,00.asp) containing excerpts from 
Richard Clarke's presentation at eWeek's Security Summit.  Among other 
things, he says "The reason you have people breaking into your software all 
over the place is because your software sucks..."

The article goes on to talk about the perceived inevitable government 
regulation of secure software development.

Cheers,

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

[SC-L] Hardened PHP (0.1.1) released

[Kenneth R. van Wyk]

FYI, I know that PHP doesn't get a lot in the way of respect in the realm of 
Software Security--and deservedly so--but there's a group that's trying to 
change that.  They've released "Hardened PHP" version 0.1.1 -- see 
http://www.hardened-php.net/index.php for details.

Among its features are (in their own words):

 - memory_limit check relocation
 - Canary protection of the Zend Memory Manager
 - Canary protection of Zend Linked Lists
 - Protection against internal format string exploits
 - Protection against arbitrary code inclusion
 - Syslog logging of attackers IP


Cheers,

Ken van Wyk
http://www.KRvW.com

[SC-L] Thanks for the suggestions for my column

[Kenneth R. van Wyk]

Hi all,

I wanted to briefly say thanks to all those that sent me ideas and suggestions 
for my upcoming columns.  Great stuff, thanks! I hope that you'll be happy to 
find that Software Security is a recurring and important theme in the 
columns, which should be launched along with the new web site by next week -- 
see http://www.eSecurityPlanet.com for details. And, of course, I certainly 
welcome your feedback.

As an aside, on the off chance that any of you are going to be attending the
FIRST (http://www.first.org) conference next month in Budapest, drop me a
note.

Cheers,

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

[SC-L] Administrivia: List outage

[Kenneth R. van Wyk]

Hi all,

Due to an inadvertent email configuration mistake at my hosting site, some 
submissions to SC-L may have been lost in the last couple of days.  If you've 
submitted something and it didn't get through, please re-submit--with my 
apologies.

Cheers,

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

[SC-L] MIT study on software development processes

[Kenneth R. van Wyk]

Hi all,

I just saw a Slashdot story 
(http://developers.slashdot.org/article.pl?sid=04/04/30/1421223&mode=thread&tid=126&tid=156&tid=185)
 
announcing an MIT study on software development processes used around the 
world.  The report itself can be found at 
http://ebusiness.mit.edu/research/papers/178_Cusumano_Intl_Comp.pdf

I haven't read through the whole thing, but the slashdot entry indicates that 
the study found some interesting things, in particular the low use of 
specification documents in the design cycle.  Although it doesn't seem to 
address security per se, I thought that SC-L readers might find it an 
interesting read nonetheless.

Cheers,

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