<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Onsite at MES: Web Security</title>
	<atom:link href="http://blogs.gartner.com/greg_young/2008/09/16/onsite-at-mes-web-security/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gartner.com/greg_young/2008/09/16/onsite-at-mes-web-security/</link>
	<description>A member of the Gartner Blog Network</description>
	<lastBuildDate>Fri, 11 Feb 2011 21:13:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Greg Young</title>
		<link>http://blogs.gartner.com/greg_young/2008/09/16/onsite-at-mes-web-security/comment-page-1/#comment-168</link>
		<dc:creator>Greg Young</dc:creator>
		<pubDate>Sat, 04 Apr 2009 17:15:38 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/greg_young/2008/09/16/onsite-at-mes-web-security/#comment-168</guid>
		<description>I couldn&#039;t agree more - avoiding vulnerabilities in the first place avoids all these band-aids.</description>
		<content:encoded><![CDATA[<p>I couldn&#8217;t agree more &#8211; avoiding vulnerabilities in the first place avoids all these band-aids.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Naithan</title>
		<link>http://blogs.gartner.com/greg_young/2008/09/16/onsite-at-mes-web-security/comment-page-1/#comment-165</link>
		<dc:creator>Naithan</dc:creator>
		<pubDate>Fri, 27 Mar 2009 21:08:13 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gartner.com/greg_young/2008/09/16/onsite-at-mes-web-security/#comment-165</guid>
		<description>Greg,

I love your blog but I have a very very quick comment. Code scanning tools are very very ineffective at providing a picture of true &quot;acceptable risk&quot; ayt the application layer. As we have seen numerous times, some of the most egregious injection, session theft, and parameter hacks have come at the expense of AD teams that coddled themselves with a false sense of security that a code scanner told them all they need to know. In fact scanners are a jumping off point for surface level issues.

As web hacking becomes the prominent form of bypassing enterprise DMZ&#039;s to get to the goodies, the logic used in the application development process is oft times not able to be detected as a flaw or vulnerability by a mere scanner. What has to happen is that early in the SDLC practices have to be implemented. 

The wrong culture in AD says that, &quot;oh we have an app going live in two weeks, is it secure? I dunno, I guess we should run a scan and patch&quot;. Then version two of that app comes out six months later and guess what? The same vulnerabilities are back. Why is that? Because developers by and large don&#039;t view application security as a part of SDLC, its just something we have to do that slows us down. 

The same applies for web app firewalls. Great tools, but they simply cannot replace secure development practices as a part of the SDLC from beginning to end. Web apps should be assessed with sound methodologies ( I am biased on this obviously but I believe it)  and practices should be honed away from poor logic, unnecessary information, black lists, and &quot;patch and go&quot; approaches etc.

again, my humble opinion</description>
		<content:encoded><![CDATA[<p>Greg,</p>
<p>I love your blog but I have a very very quick comment. Code scanning tools are very very ineffective at providing a picture of true &#8220;acceptable risk&#8221; ayt the application layer. As we have seen numerous times, some of the most egregious injection, session theft, and parameter hacks have come at the expense of AD teams that coddled themselves with a false sense of security that a code scanner told them all they need to know. In fact scanners are a jumping off point for surface level issues.</p>
<p>As web hacking becomes the prominent form of bypassing enterprise DMZ&#8217;s to get to the goodies, the logic used in the application development process is oft times not able to be detected as a flaw or vulnerability by a mere scanner. What has to happen is that early in the SDLC practices have to be implemented. </p>
<p>The wrong culture in AD says that, &#8220;oh we have an app going live in two weeks, is it secure? I dunno, I guess we should run a scan and patch&#8221;. Then version two of that app comes out six months later and guess what? The same vulnerabilities are back. Why is that? Because developers by and large don&#8217;t view application security as a part of SDLC, its just something we have to do that slows us down. </p>
<p>The same applies for web app firewalls. Great tools, but they simply cannot replace secure development practices as a part of the SDLC from beginning to end. Web apps should be assessed with sound methodologies ( I am biased on this obviously but I believe it)  and practices should be honed away from poor logic, unnecessary information, black lists, and &#8220;patch and go&#8221; approaches etc.</p>
<p>again, my humble opinion</p>
]]></content:encoded>
	</item>
</channel>
</rss>

