Re: DHS Open Source Hardening Project

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
On Tue, 20 May 2008 10:07:52 -0400 "max bianco"
<maximilianbianco@xxxxxxxxx> wrote
> 
> >> On Mon, 2008-05-19 at 14:13 -0400, McGuffey, David C. wrote:
> >> > I understand that DHS is funding an effort to use commercial
tools
> > to
> >> > find bugs in open source software.  I guess the official name is
> >> > Vulnerability Discovery and Remediation, Open Source Hardening
> > Project,
> >> > but the common handle seems to be simply Open Source Hardening
> > Project.
> >> >
> >> > There was an interesting article at ZDnet...some pros and some
cons:
> >> > http://news.zdnet.com/2100-1009_22-6025579.html
> >> >
> >> > Question...is the Fedora development community benefiting from
this
> >> > effort?
> >> >
> >> > Dave McGuffey
> >>
> >> Did you look at the date of the article?
> >>
> >> Regards,
> >> Les H
> >>
> > Yes, but it was mentioned at the 8th Software Assurance Forum two
weeks
> > ago in and among several presentations concerning open software
> > security. So...apparently the program is still going on.
> >
> > There were other presentations about automated tools that scan
through
> > both source and compiled binaries looking for actual or potential
> > vulnerabilities.  In some cases the code is so complex, that the
tools
> > can only flag a block of code for further human review.  Seems that
a
> > lot of effort is going into automated tools, because a significant
> > percentage of the attendees at the SWaF seems to believe that the
> > universities are doing a poor job of training software engineers,
and
> > the "cost schedule" mantra of software development managers runs
counter
> > to security.
> 
> Do you have any good links or information for programmers looking to
> tighten up code in regards to security? I have seen some things
> scattered about but I was hoping to find some central repository of
> info(if such exists) that points out the common flaws and how to fix
> them or even better how to avoid them. I don't think anyone is trying
> to leaving gaping security holes in their software but its obviously
> happening anyway. I have seen among some of the redhat stuff, I have
> read, pointers that show common errors but I am looking for something
> like a book(i don't mind paying for solid information) that teaches
> how to program securely, maybe something that explains how to avoid
> the common errors starting in the planning phase. I know such a book
> would not be easy to produce but it would be worth paying for if it
> can help people code more securely. A well written book on programming
> should take these things into consideration but there are many books,
> some obviously better written than others but unless you already have
> the expertise it is going to be hard to tell the difference. I google
> for it and i get alot of hits but these pages are ranked on
> popularity, in part anyway, and there is no guarantee that the info is
> up to date or even accurate. I wouldn't mind seeing my tax dollars
> spent on something useful like a knowledge base where programmers can
> turn for good advice on best practices and such.The world gets more
> dependent on software everyday, we need better quality control. BTW i
> am not suggesting such a thing would be easy but the things worth
> doing rarely are...
> 
> 
> Max
>
I'm in a similar boat...just getting into this area.  On past programs,
I've had to locate and/or merge guidance from various sources for a
particular language (e.g., C or Java). Whatever I've assembled seems to
be out of date before the program is finished.  There are a lot of
guides out there.  DISA has some guidance in their STIGs for the DoD
community.  The new DHS site (Building Security In)
https://buildsecurityin.us-cert.gov/daisy/bsi/home.html has a lot of
material and links to more material on this topic.

While at the 8th SWAF, one author seemed to always come to the forefront
of many discussions...Gary McGraw.  He has spoken at a number of
conferences, written a lot of articles in "Dark Reading" and has
co-authored three books.  I skimmed through the books while at the SWAF
and was impressed with the content, so I ordered all three.  They are:
"Building Secure Software" by John Viega and Gary McGraw (The White Hat
view); "Exploiting Software" by Greg Hoglund and Gary McGraw (The Black
Hat view); and "Software Security, Building Security In" by Gary McGraw
(A blended view).  The last one, has the same name of the DHS website,
so I'll assume that he wrote it to complement their efforts. 

Between the DHS site and these three books, I'll count it as a good
start...but certainly not the end of the road or any silver bullet to
the problems.

WRT my original question, whatever impact the DHS initiative may have on
open source, seems to be well upstream from the Fedora Project.

Dave McGuffey
Principal Information System Security Engineer // NSA-IEM, NSA-IAM
SAIC, IISBU, Columbia, MD


-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux