[Owasp-topten] Feedback on OWASP 2010 Top 10 (Sec. Misconfig)
dave.wichers at aspectsecurity.com
Tue Nov 17 14:37:01 EST 2009
I think that ends up with too broad of a category and the issues are different in my opinion.
From: Ralph Durkee <rd at rd1.net>
Sent: Tuesday, November 17, 2009 10:40 AM
To: Dave Wichers <dave.wichers at aspectsecurity.com>
Cc: Dave Wichers <dave.wichers at aspectsecurity.com>; <owasp-topten at lists.owasp.org> <owasp-topten at lists.owasp.org>
Subject: Re: [Owasp-topten] Feedback on OWASP 2010 Top 10 (Sec. Misconfig)
No. I was thinking we wouldn't drop configuration from the title.
Just add archecture. Something like
Insecure configuration and archecture
On Nov 17, 2009, at 10:07 AM, "Dave Wichers" <dave.wichers at aspectsecurity.com
> I think taking configuration out of the title would take away from
> the primary focus of that top 10 area.
> -----Original Message-----
> From: Ralph Durkee <rd at rd1.net>
> Sent: Tuesday, November 17, 2009 9:00 AM
> To: Dave Wichers <dave.wichers at aspectsecurity.com>
> Cc: owasp-topten at lists.owasp.org <owasp-topten at lists.owasp.org>
> Subject: Re: [Owasp-topten] Feedback on OWASP 2010 Top 10 (Sec.
> Yes that helps. Some of what you described as misconfiguration is
> I was describing as architecture. Is there multiple tiers, what
> services and roles do each tier provide, what communications are used
> between the systems and components. Are insecure services and
> used, or services that are inappropriate for the architecture, such as
> SMB or NFS on the web server. Is there XML gateway or Web App
> would included. Frameworks used is also architecture. Many (not
> all) of
> these architect issues will come to light with a manual review of
> automated scans. Why not broaden the title to include insecure
> -- Ralph Durkee, CISSP, GSEC, GCIH, GSNA, GPEN
> Principal Security Consultant
> Dave Wichers wrote:
>> My thoughts on security misconfiguration is that it covers the
>> configuration of everything on the server that is hosting the web
>> application as well as anything else in front of that server that is
>> protecting it (at least at the app layer for the 'in front'
>> And it includes the configuration (again at the app layer) of any
>> back-end components accessed by the web app, like the database/DB
>> So, for the app server, this includes the OS, the app server, the app
>> itself, and any components/frameworks used by the app that are
>> configurable. For a front end component, like an XML gateway, or App
>> Firewall, then I'd be primarily focused on their app layer
>> (although their network configuration is important too).
>> As an organization, we recommend increased focus on the app layer
>> configuration of all the components involved since most organizations
>> tend to currently focus on the network layer components. As part of
>> configuration, keeping up with the latest version of all the software
>> components involved is also very important as half the patches issued
>> are fixing security flaws, even in libraries, like Struts, Spring,
>> I would expect both app and network layer scanning to help detect
>> security configuration flaws, as well as manual analysis. Neither
>> can do
>> this well on its own, but manual analysis is probably the most
>> aspect for the app layer.
>> I don't know if this clarifies my thoughts on the subject, but
>> it does.
>> I'm not sure what you mean by architecture issues that can be
>> by review of automated scan results.
>> -----Original Message-----
>> From: owasp-topten-bounces at lists.owasp.org
>> [mailto:owasp-topten-bounces at lists.owasp.org] On Behalf Of Ralph
>> Sent: Monday, November 16, 2009 9:57 AM
>> To: owasp-topten at lists.owasp.org
>> Subject: [Owasp-topten] Feedback on OWASP 2010 Top 10 (Sec.
>> Bringing back the "Security Misconfiguration" certainly deserves some
>> discussion. As I remember the logic for taking it out was that it
>> more in the realm of Web Sever vulnerabilities then Web
>> Application. I
>> agree on the risk rating, but if you consider that these
>> should be easily detected with host based and network based
>> vulnerabilities scanners, as oppose to Web Application Scanners.
>> As I'm
>> thinking this one doesn't belong. Otherwise we could include
>> issues as well.
>> However on a related thread of thought, Web Application architecture
>> issues are specific to web applications, and probably deserve to be
>> included. Although I would have to say that most of the architecture
>> issues could be detected by a manual review of automated scans.
>> Maybe there's a third option if there's a reasonable way to combine
>> Web App architecture and configuration issues into a reasonable
>> -- Ralph Durkee
>> Owasp-topten mailing list
>> Owasp-topten at lists.owasp.org
More information about the Owasp-topten