<?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 for Systems Security</title>
	<atom:link href="http://www.cs.ox.ac.uk/blogs/sss/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.cs.ox.ac.uk/blogs/sss</link>
	<description></description>
	<lastBuildDate>Wed, 03 Apr 2013 20:55:16 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>Comment on Where is all the nodejs malware? by Saqib Ali</title>
		<link>http://www.cs.ox.ac.uk/blogs/sss/2013/04/02/why-isnt-there-any-nodejs-malware/#comment-1145</link>
		<dc:creator>Saqib Ali</dc:creator>
		<pubDate>Wed, 03 Apr 2013 20:55:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.cs.ox.ac.uk/blogs/sss/?p=291#comment-1145</guid>
		<description><![CDATA[Disagree? Not at all. In fact this is a real risk. It has happened with jquery. 

One thing that I do to detect these type of malware infestation is constantly run network analysis on the webservers that is serving our apps. It sends us a daily report of all the network connections of all types. We visually inspect the report to see if there are anything out of order. You have to do this visually. It is unlikely that a automated system will detect this type of anomaly. But once you are familiar with the traffic patterns of your app, it only takes few minutes to inspect the daily network report.

We are in the process of setting up a client machine that mimics the user on the webapp, The plan is to run the same network analysis on the client to see if there any anomalies in the network traffic. That should take care of client side javascript malware in the webapp.]]></description>
		<content:encoded><![CDATA[<p>Disagree? Not at all. In fact this is a real risk. It has happened with jquery. </p>
<p>One thing that I do to detect these type of malware infestation is constantly run network analysis on the webservers that is serving our apps. It sends us a daily report of all the network connections of all types. We visually inspect the report to see if there are anything out of order. You have to do this visually. It is unlikely that a automated system will detect this type of anomaly. But once you are familiar with the traffic patterns of your app, it only takes few minutes to inspect the daily network report.</p>
<p>We are in the process of setting up a client machine that mimics the user on the webapp, The plan is to run the same network analysis on the client to see if there any anomalies in the network traffic. That should take care of client side javascript malware in the webapp.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on cloud failure modalities by footnote &#124; Systems Security</title>
		<link>http://www.cs.ox.ac.uk/blogs/sss/2011/07/23/cloud-failure-modalities/#comment-16</link>
		<dc:creator>footnote &#124; Systems Security</dc:creator>
		<pubDate>Wed, 27 Jul 2011 08:55:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.cs.ox.ac.uk/blogs/sss/?p=148#comment-16</guid>
		<description><![CDATA[[...] post on cloud failure modalities made passing reference to someone whose Google existence had been snuffed out for no adequately [...]]]></description>
		<content:encoded><![CDATA[<p>[...] post on cloud failure modalities made passing reference to someone whose Google existence had been snuffed out for no adequately [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Outsourcing undermined by cloud failure modalities &#124; Systems Security</title>
		<link>http://www.cs.ox.ac.uk/blogs/sss/2011/06/30/outsourcing-undermined/#comment-15</link>
		<dc:creator>cloud failure modalities &#124; Systems Security</dc:creator>
		<pubDate>Sat, 23 Jul 2011 12:32:41 +0000</pubDate>
		<guid isPermaLink="false">http://trustusoxford.wordpress.com/?p=59#comment-15</guid>
		<description><![CDATA[[...] topic mentioned in an earlier article is also germane: the legal jurisdiction in which the service provider sits may be far from clear [...]]]></description>
		<content:encoded><![CDATA[<p>[...] topic mentioned in an earlier article is also germane: the legal jurisdiction in which the service provider sits may be far from clear [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on email retention by Andrew Martin</title>
		<link>http://www.cs.ox.ac.uk/blogs/sss/2011/07/11/email-retention/#comment-10</link>
		<dc:creator>Andrew Martin</dc:creator>
		<pubDate>Wed, 13 Jul 2011 18:38:21 +0000</pubDate>
		<guid isPermaLink="false">http://trustusoxford.wordpress.com/?p=69#comment-10</guid>
		<description><![CDATA[That&#039;s interesting. I thought that for some (I would name names, but perhaps that is unwise)  it was explicitly to avoid retaining discussions they&#039;d rather not report.   But maybe that&#039;s how everyone understands it, but not the corporate position.

The Data Protection Act compels us to retain personal information no longer than is necessary.  But few are sure how long is necessary.]]></description>
		<content:encoded><![CDATA[<p>That&#8217;s interesting. I thought that for some (I would name names, but perhaps that is unwise)  it was explicitly to avoid retaining discussions they&#8217;d rather not report.   But maybe that&#8217;s how everyone understands it, but not the corporate position.</p>
<p>The Data Protection Act compels us to retain personal information no longer than is necessary.  But few are sure how long is necessary.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Outsourcing undermined by Joe Loughry</title>
		<link>http://www.cs.ox.ac.uk/blogs/sss/2011/06/30/outsourcing-undermined/#comment-7</link>
		<dc:creator>Joe Loughry</dc:creator>
		<pubDate>Tue, 12 Jul 2011 20:55:50 +0000</pubDate>
		<guid isPermaLink="false">http://trustusoxford.wordpress.com/?p=59#comment-7</guid>
		<description><![CDATA[In a further discussion on cloud computing security this morning, someone mentioned that if law enforcement decides to seize your provider’s servers—even for an offence perpetrated by another customer of the provider—you may lose access to YOUR data without warning and for a long time.

Replication is the solution: with $n$-seizure-tolerant fail-over, keep on computing even as law enforcement officers unrack machines in one data centre! Wonder if that business opportunity has been pitched to VCs yet.]]></description>
		<content:encoded><![CDATA[<p>In a further discussion on cloud computing security this morning, someone mentioned that if law enforcement decides to seize your provider’s servers—even for an offence perpetrated by another customer of the provider—you may lose access to YOUR data without warning and for a long time.</p>
<p>Replication is the solution: with $n$-seizure-tolerant fail-over, keep on computing even as law enforcement officers unrack machines in one data centre! Wonder if that business opportunity has been pitched to VCs yet.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on email retention by Joe Loughry</title>
		<link>http://www.cs.ox.ac.uk/blogs/sss/2011/07/11/email-retention/#comment-9</link>
		<dc:creator>Joe Loughry</dc:creator>
		<pubDate>Tue, 12 Jul 2011 20:54:36 +0000</pubDate>
		<guid isPermaLink="false">http://trustusoxford.wordpress.com/?p=69#comment-9</guid>
		<description><![CDATA[Financial institutions in the U.S. save every communication: they scan both sides of every piece of paper that comes in the post, archive email, instant messages, and record every telephone call. But traders use their personal mobiles to avoid the surveillance net.

Other companies won’t admit they delete emails as a litigation defence; if pressed, they claim that storage space for mboxes is excessive and costing them too much.

I worry about the loss of institutional memory; after a desktop hard disk failure, a few tech refresh cycles, building moves and corporate email system upgrades, it’s a wonder anyone can find the documentation from a project more than a few years old. Multiply the lost NASA moon landing tapes by a few million companies’ haphazard IT infrastructure, and 1995–2010 might be reckoned by future historians another Dark Age.]]></description>
		<content:encoded><![CDATA[<p>Financial institutions in the U.S. save every communication: they scan both sides of every piece of paper that comes in the post, archive email, instant messages, and record every telephone call. But traders use their personal mobiles to avoid the surveillance net.</p>
<p>Other companies won’t admit they delete emails as a litigation defence; if pressed, they claim that storage space for mboxes is excessive and costing them too much.</p>
<p>I worry about the loss of institutional memory; after a desktop hard disk failure, a few tech refresh cycles, building moves and corporate email system upgrades, it’s a wonder anyone can find the documentation from a project more than a few years old. Multiply the lost NASA moon landing tapes by a few million companies’ haphazard IT infrastructure, and 1995–2010 might be reckoned by future historians another Dark Age.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Outsourcing undermined by J. Loughry</title>
		<link>http://www.cs.ox.ac.uk/blogs/sss/2011/06/30/outsourcing-undermined/#comment-6</link>
		<dc:creator>J. Loughry</dc:creator>
		<pubDate>Thu, 07 Jul 2011 23:19:41 +0000</pubDate>
		<guid isPermaLink="false">http://trustusoxford.wordpress.com/?p=59#comment-6</guid>
		<description><![CDATA[&#039;...they either break US law or they break EU law.&#039;

This needs to be more widely publicised.]]></description>
		<content:encoded><![CDATA[<p>&#8216;&#8230;they either break US law or they break EU law.&#8217;</p>
<p>This needs to be more widely publicised.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on on an unfortunate tension by J. Loughry</title>
		<link>http://www.cs.ox.ac.uk/blogs/sss/2011/06/20/on-an-unfortunate-tension/#comment-5</link>
		<dc:creator>J. Loughry</dc:creator>
		<pubDate>Thu, 07 Jul 2011 23:06:22 +0000</pubDate>
		<guid isPermaLink="false">http://trustusoxford.wordpress.com/?p=44#comment-5</guid>
		<description><![CDATA[Of the channels presently available---802.11, Bluetooth, IR, acoustic or HDSPA---I agree 802.11 has the right combination of features: power enough to communicate with a large space without requiring an unreasonably large number of transceivers in the venue, non-line-of-sight so that devices in pockets and bags and participate, and fairly low power requirements.  What is missing is a protocol and an incentive for manufacturers to follow it.  Man pages for Ethernet cards on FreeBSD or Linux are full of complaints from device driver writers about corner-cutting hardware manufacturers, incompletely or incorrectly implement standard interfaces and protocols, claimed features of the hardware that do not work, and firmware updates without corresponding version number changes.  The new protocol must be implemented as high in the OSI model as possible, because otherwise we can&#039;t depend on all the hardware manufacturers writing the functionality in their firmware.  It either has to be done at the PHY level (by the two or three suppliers who actually make the radios everyone else uses) or at the device driver level.  In between, there is opportunity for manufacturers to cheat.]]></description>
		<content:encoded><![CDATA[<p>Of the channels presently available&#8212;802.11, Bluetooth, IR, acoustic or HDSPA&#8212;I agree 802.11 has the right combination of features: power enough to communicate with a large space without requiring an unreasonably large number of transceivers in the venue, non-line-of-sight so that devices in pockets and bags and participate, and fairly low power requirements.  What is missing is a protocol and an incentive for manufacturers to follow it.  Man pages for Ethernet cards on FreeBSD or Linux are full of complaints from device driver writers about corner-cutting hardware manufacturers, incompletely or incorrectly implement standard interfaces and protocols, claimed features of the hardware that do not work, and firmware updates without corresponding version number changes.  The new protocol must be implemented as high in the OSI model as possible, because otherwise we can&#8217;t depend on all the hardware manufacturers writing the functionality in their firmware.  It either has to be done at the PHY level (by the two or three suppliers who actually make the radios everyone else uses) or at the device driver level.  In between, there is opportunity for manufacturers to cheat.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Spectacular Fail! by Andrew Martin</title>
		<link>http://www.cs.ox.ac.uk/blogs/sss/2011/07/07/spectacular-fail/#comment-8</link>
		<dc:creator>Andrew Martin</dc:creator>
		<pubDate>Thu, 07 Jul 2011 19:14:49 +0000</pubDate>
		<guid isPermaLink="false">http://trustusoxford.wordpress.com/?p=65#comment-8</guid>
		<description><![CDATA[Postscript: it transpires that IE9 doesn&#039;t work on WinXP.  Microsoft offers IE8 instead.]]></description>
		<content:encoded><![CDATA[<p>Postscript: it transpires that IE9 doesn&#8217;t work on WinXP.  Microsoft offers IE8 instead.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on on an unfortunate tension by Andrew Martin</title>
		<link>http://www.cs.ox.ac.uk/blogs/sss/2011/06/20/on-an-unfortunate-tension/#comment-4</link>
		<dc:creator>Andrew Martin</dc:creator>
		<pubDate>Thu, 07 Jul 2011 08:36:03 +0000</pubDate>
		<guid isPermaLink="false">http://trustusoxford.wordpress.com/?p=44#comment-4</guid>
		<description><![CDATA[I&#039;m sure that such a signalling regime has its place.  

But surely the problem is with the non-compliant devices (and their owners) - always assuming, again, that electrical interference in commercial avionics is actually a problem.  I&#039;m not sure how you would incentivize a global standard: there&#039;s little in it for the vendors.  Moreover, I don&#039;t think you could realistically ensure that all airport security checkpoints could weed out the rogue devices, any more than the cabin crew can.  Economically, I&#039;m not sure it&#039;s a problem anyone wants to solve.

The problem of recognition is going to become a bigger and bigger one, though.  Having more and more devices able securely to report their identity - in a privacy-sensitive way - is definitely a desirable thing.  Having 802.11 as the bearer for that seems overwhelmingly likely to me.]]></description>
		<content:encoded><![CDATA[<p>I&#8217;m sure that such a signalling regime has its place.  </p>
<p>But surely the problem is with the non-compliant devices (and their owners) &#8211; always assuming, again, that electrical interference in commercial avionics is actually a problem.  I&#8217;m not sure how you would incentivize a global standard: there&#8217;s little in it for the vendors.  Moreover, I don&#8217;t think you could realistically ensure that all airport security checkpoints could weed out the rogue devices, any more than the cabin crew can.  Economically, I&#8217;m not sure it&#8217;s a problem anyone wants to solve.</p>
<p>The problem of recognition is going to become a bigger and bigger one, though.  Having more and more devices able securely to report their identity &#8211; in a privacy-sensitive way &#8211; is definitely a desirable thing.  Having 802.11 as the bearer for that seems overwhelmingly likely to me.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
