<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Second Crack at SCADA Issues</title>
	<link>http://www.blindside.org.uk/2007/08/28/second-crack-at-scada-issues/</link>
	<description>What's going to go wrong in our e-enabled world?</description>
	<pubDate>Sat, 22 Nov 2008 12:09:40 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: Tom Fuller</title>
		<link>http://www.blindside.org.uk/2007/08/28/second-crack-at-scada-issues/#comment-2448</link>
		<dc:creator>Tom Fuller</dc:creator>
		<pubDate>Fri, 07 Sep 2007 12:42:56 +0000</pubDate>
		<guid>http://www.blindside.org.uk/2007/08/28/second-crack-at-scada-issues/#comment-2448</guid>
		<description>Well, Phil, considering this is exactly what I hoped someone would do, how do I thank you? Well done. Wait--I know! Would you please know do this for every post I have ever written? (I could give you URLs of other blogs in addition to this one.) You've set the standard.</description>
		<content:encoded><![CDATA[<p>Well, Phil, considering this is exactly what I hoped someone would do, how do I thank you? Well done. Wait&#8211;I know! Would you please know do this for every post I have ever written? (I could give you URLs of other blogs in addition to this one.) You&#8217;ve set the standard.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phil</title>
		<link>http://www.blindside.org.uk/2007/08/28/second-crack-at-scada-issues/#comment-2447</link>
		<dc:creator>Phil</dc:creator>
		<pubDate>Fri, 07 Sep 2007 12:00:06 +0000</pubDate>
		<guid>http://www.blindside.org.uk/2007/08/28/second-crack-at-scada-issues/#comment-2447</guid>
		<description>I have looked at the security of a number of large scale SCADA and some CNI SCADA. Here are the problems that come to mind immediately.

The PLCs are very low powered (in computing terms) devices which has led to highly efficient but low security code being developed. Also makes deploying network level encryption very hard.

PLCs have system lifecycles of up to 25 years meaning noone is getting replacements any time soon. 

To patch a PLC for many of them requires physicaly visiting them and replacing the firmware with custom written code over a serial link, not feasible in estates with 10s of thousands of PLCs across large campuses or distributed around the country.

The PLCs were originally serial, the move to Ethernet (Or a variant of) generally meant wrapping a serial protocol up in an ethernet frame. The move to IP has meant wrapping those up again in an IP packet. No consideration was given in the protocol design to the threats in an IP environment.

There are no good security testing tools for the legacy SCADA protocols in the public domain. I know some end users are scanning PLCs with standard IT vulnerability scanners like nessus and assuming that tells them something about the state of their systems. We need ModBus network fuzzers and the like. These already exist in private.

Those PLCs that have had IP stacks and web servers added are generally used for monitoring rather than control (although this is changing). In general there is a good bet that the custom IP stack will have a flaw allowing at a minimum for denial of service and the web server will be using vanilla HTTP without authentication.

Somewhere along the line the SCADA industry decided to standardise on Microsoft DCOM as the transport for their interoperable control protocol OPC. Anyone from the more technical end of security would know thats like building a malaria hospital in a swamp. Just look at the number of OPC tunneling products that have been created to get OPC past corporate firewalls or the fact that the complexity of getting DCOM based authentication working across different domains/ADs means most deployments allow anonymous or unauthenticated access for simplicity. Then look at the number of DCOM vulnerabilities found in the early 2000s and remember the OPC clients/servers haven't had that level of scrutiny applied yet.

There are plenty of other problems but imagine the SCADA/PLC world is where the Internet was 10 years ago, many the same sorts of problems will be found and need to be fixed and at the moment there is no way to deploy those fixes or a way to deploy new versions with the built in as part of the system refresh cycle.</description>
		<content:encoded><![CDATA[<p>I have looked at the security of a number of large scale SCADA and some CNI SCADA. Here are the problems that come to mind immediately.</p>
<p>The PLCs are very low powered (in computing terms) devices which has led to highly efficient but low security code being developed. Also makes deploying network level encryption very hard.</p>
<p>PLCs have system lifecycles of up to 25 years meaning noone is getting replacements any time soon. </p>
<p>To patch a PLC for many of them requires physicaly visiting them and replacing the firmware with custom written code over a serial link, not feasible in estates with 10s of thousands of PLCs across large campuses or distributed around the country.</p>
<p>The PLCs were originally serial, the move to Ethernet (Or a variant of) generally meant wrapping a serial protocol up in an ethernet frame. The move to IP has meant wrapping those up again in an IP packet. No consideration was given in the protocol design to the threats in an IP environment.</p>
<p>There are no good security testing tools for the legacy SCADA protocols in the public domain. I know some end users are scanning PLCs with standard IT vulnerability scanners like nessus and assuming that tells them something about the state of their systems. We need ModBus network fuzzers and the like. These already exist in private.</p>
<p>Those PLCs that have had IP stacks and web servers added are generally used for monitoring rather than control (although this is changing). In general there is a good bet that the custom IP stack will have a flaw allowing at a minimum for denial of service and the web server will be using vanilla HTTP without authentication.</p>
<p>Somewhere along the line the SCADA industry decided to standardise on Microsoft DCOM as the transport for their interoperable control protocol OPC. Anyone from the more technical end of security would know thats like building a malaria hospital in a swamp. Just look at the number of OPC tunneling products that have been created to get OPC past corporate firewalls or the fact that the complexity of getting DCOM based authentication working across different domains/ADs means most deployments allow anonymous or unauthenticated access for simplicity. Then look at the number of DCOM vulnerabilities found in the early 2000s and remember the OPC clients/servers haven&#8217;t had that level of scrutiny applied yet.</p>
<p>There are plenty of other problems but imagine the SCADA/PLC world is where the Internet was 10 years ago, many the same sorts of problems will be found and need to be fixed and at the moment there is no way to deploy those fixes or a way to deploy new versions with the built in as part of the system refresh cycle.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: wendyg</title>
		<link>http://www.blindside.org.uk/2007/08/28/second-crack-at-scada-issues/#comment-2199</link>
		<dc:creator>wendyg</dc:creator>
		<pubDate>Tue, 28 Aug 2007 17:39:27 +0000</pubDate>
		<guid>http://www.blindside.org.uk/2007/08/28/second-crack-at-scada-issues/#comment-2199</guid>
		<description>Yes - the Forbes article is pretty scary reading.

wg</description>
		<content:encoded><![CDATA[<p>Yes - the Forbes article is pretty scary reading.</p>
<p>wg</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ian Brown</title>
		<link>http://www.blindside.org.uk/2007/08/28/second-crack-at-scada-issues/#comment-2192</link>
		<dc:creator>Ian Brown</dc:creator>
		<pubDate>Tue, 28 Aug 2007 09:08:49 +0000</pubDate>
		<guid>http://www.blindside.org.uk/2007/08/28/second-crack-at-scada-issues/#comment-2192</guid>
		<description>I think that as far as possible, these systems should simply be air-gapped from WANs and most especially the Internet.</description>
		<content:encoded><![CDATA[<p>I think that as far as possible, these systems should simply be air-gapped from WANs and most especially the Internet.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.112 seconds -->
