<?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"
	>
<channel>
	<title>Comments on: Should states lead the charge for secure application development?</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/security-bytes/should-states-lead-the-charge-for-secure-application-development/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/security-bytes/should-states-lead-the-charge-for-secure-application-development/</link>
	<description>A SearchSecurity.com blog</description>
	<pubDate>Sun, 29 Nov 2009 12:03:42 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Mike</title>
		<link>http://itknowledgeexchange.techtarget.com/security-bytes/should-states-lead-the-charge-for-secure-application-development/#comment-585</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Wed, 28 Jan 2009 16:18:04 +0000</pubDate>
		<guid isPermaLink="false">http://security.blogs.techtarget.com/2009/01/15/should-states-lead-the-charge-for-secure-application-development/#comment-585</guid>
		<description>I don’t think that this is necessarily a bad idea, the credit card companies have been trying to do this for years with PABP (Payment Application Best Practices) and these include many more security features than just credit card related items. Mainly securing all data stored in an application. In the 25 Dangerous Programming Errors, the first category should be a no brainer “Insecure Interaction between Components.” Every software developer should be protecting their software from the errors in this category. The second category would be a little harder for some smaller companies and custom programs. The third category is also one that should be easy enough for even the small companies to implement. My thought for software having criteria like this is not for it to be government controlled but it should be market controlled. I will go back to my example of PABP and that Visa says now that they will only accept new merchants if they are PCI compliant and in order for a merchant to be PCI compliant they must be using a software application that is compliant with PABP. I also believe that it is a great selling point for software to show that you follow the security standards and have been certified by another company saying that your software is secure over the competitions.</description>
		<content:encoded><![CDATA[<p>I don’t think that this is necessarily a bad idea, the credit card companies have been trying to do this for years with PABP (Payment Application Best Practices) and these include many more security features than just credit card related items. Mainly securing all data stored in an application. In the 25 Dangerous Programming Errors, the first category should be a no brainer “Insecure Interaction between Components.” Every software developer should be protecting their software from the errors in this category. The second category would be a little harder for some smaller companies and custom programs. The third category is also one that should be easy enough for even the small companies to implement. My thought for software having criteria like this is not for it to be government controlled but it should be market controlled. I will go back to my example of PABP and that Visa says now that they will only accept new merchants if they are PCI compliant and in order for a merchant to be PCI compliant they must be using a software application that is compliant with PABP. I also believe that it is a great selling point for software to show that you follow the security standards and have been certified by another company saying that your software is secure over the competitions.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- dynamic -->