<?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: Developing Secure Code</title>
	<atom:link href="http://un-excogitate.org/archives/2007/07/22/developing-secure-code/feed/" rel="self" type="application/rss+xml" />
	<link>http://un-excogitate.org/archives/2007/07/22/developing-secure-code/</link>
	<description>what was I thinking? (Christian Frichot's ad-lib on security and what-not)</description>
	<lastBuildDate>Wed, 10 Mar 2010 00:27:08 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: For Developers, an Ounce of Prevention is Worth a Pound of Cure - Network Sentry</title>
		<link>http://un-excogitate.org/archives/2007/07/22/developing-secure-code/comment-page-1/#comment-8085</link>
		<dc:creator>For Developers, an Ounce of Prevention is Worth a Pound of Cure - Network Sentry</dc:creator>
		<pubDate>Wed, 17 Oct 2007 19:04:29 +0000</pubDate>
		<guid isPermaLink="false">http://un-excogitate.org/archives/2007/07/22/developing-secure-code/#comment-8085</guid>
		<description>[...] This un-excogitate posting summarizes an earlier article at MSDN Magazine that delineates eight rules software writers should follow in order to create secure code. On the list: &#8220;never trust data&#8221;; use threat modeling and keep abreast of emerging threats and vulnerabilities; and use fuzz input testing. (A response to the post said these three were the only worthwhile tips.) [...]</description>
		<content:encoded><![CDATA[<p>[...] This un-excogitate posting summarizes an earlier article at MSDN Magazine that delineates eight rules software writers should follow in order to create secure code. On the list: &#8220;never trust data&#8221;; use threat modeling and keep abreast of emerging threats and vulnerabilities; and use fuzz input testing. (A response to the post said these three were the only worthwhile tips.) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hi, Super Nintendo Chalmers!</title>
		<link>http://un-excogitate.org/archives/2007/07/22/developing-secure-code/comment-page-1/#comment-7394</link>
		<dc:creator>Hi, Super Nintendo Chalmers!</dc:creator>
		<pubDate>Wed, 15 Aug 2007 14:56:35 +0000</pubDate>
		<guid isPermaLink="false">http://un-excogitate.org/archives/2007/07/22/developing-secure-code/#comment-7394</guid>
		<description># Never trust data
# Use threat modeling against your code
# Use fuzz input testing

These are about the only good things he has to say. I mean really &#039;write secure code&#039;?

Stay one step ahead - This is silly! 90% of the attacks on [badly written] applications are due to poor input validation. He could at least talk to the software development lifecycle and introduce aspects of security within such a framework, rather than the 8 half arsed steps to looking like you know both security and software development. At what point does MH get the security requirements for his application? Where does he assess the risk of the threats he has identified? I could carry on but I&#039;m lazy and you can do your own research!

Tools tools tools... liek if we fuzz the shit out of the application we will have secure code coz the leet haxors wont be able to break it! Sure fuzzing is the flavour of the month and has helped many a hacker, security professional and code monkey find flaws that would have previously taken vast amounts of time to find but it is not a panacea. 

Now you say that these principals apply to everyone from you one man band to your big Indian development houses. Do you really envisage a one man band to go get the latest fuzzing tool to test on their dodgy PHP application? Do you think that apart from the aforementioned three salient points that a big software shop is going to tell its developers “don&#039;t write insecure code”? For crying out loud he even uses a double negative! I would rather we as security professionals tell people to write secure code. It is almost like telling Ralph not to pick his nose!....Fucking futile endevour if you ask me. 

Check out SP 800-64, it might be a bit longer than a blog post on the official MSDN blog but it will be more worthwhile.</description>
		<content:encoded><![CDATA[<p># Never trust data<br />
# Use threat modeling against your code<br />
# Use fuzz input testing</p>
<p>These are about the only good things he has to say. I mean really &#8216;write secure code&#8217;?</p>
<p>Stay one step ahead &#8211; This is silly! 90% of the attacks on [badly written] applications are due to poor input validation. He could at least talk to the software development lifecycle and introduce aspects of security within such a framework, rather than the 8 half arsed steps to looking like you know both security and software development. At what point does MH get the security requirements for his application? Where does he assess the risk of the threats he has identified? I could carry on but I&#8217;m lazy and you can do your own research!</p>
<p>Tools tools tools&#8230; liek if we fuzz the shit out of the application we will have secure code coz the leet haxors wont be able to break it! Sure fuzzing is the flavour of the month and has helped many a hacker, security professional and code monkey find flaws that would have previously taken vast amounts of time to find but it is not a panacea. </p>
<p>Now you say that these principals apply to everyone from you one man band to your big Indian development houses. Do you really envisage a one man band to go get the latest fuzzing tool to test on their dodgy PHP application? Do you think that apart from the aforementioned three salient points that a big software shop is going to tell its developers “don&#8217;t write insecure code”? For crying out loud he even uses a double negative! I would rather we as security professionals tell people to write secure code. It is almost like telling Ralph not to pick his nose!&#8230;.Fucking futile endevour if you ask me. </p>
<p>Check out SP 800-64, it might be a bit longer than a blog post on the official MSDN blog but it will be more worthwhile.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
