<?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: SSN Records at UChicago Compromised</title>
	<atom:link href="http://blog.ebrahim.org/2005/05/28/ssn-records-at-uchicago-compromised/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.ebrahim.org/2005/05/28/ssn-records-at-uchicago-compromised/</link>
	<description>Ali Ebrahim on web standards, software developement, technology, politics and law.</description>
	<lastBuildDate>Tue, 07 Feb 2012 08:34:33 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
	<item>
		<title>By: Mark</title>
		<link>http://blog.ebrahim.org/2005/05/28/ssn-records-at-uchicago-compromised/comment-page-1/#comment-356</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Mon, 30 May 2005 05:18:15 +0000</pubDate>
		<guid isPermaLink="false">http://blog.ebrahim.org/2005/05/28/ssn-records-at-uchicago-compromised/#comment-356</guid>
		<description>I&#039;m not sure if this could really be called a &quot;compromise&quot; since there has been no &quot;incident&quot; (at the moment, no one is known to have stolen the data), but it is a severe security violation.

I&#039;m glad that deligent Residential Computing staff found the information, but I do find it dubious that the information ended up on krypton in the first place.  I am disappointed as well that that would occur.

The window of opportunity has also been sporadic since Rescom people have combing through the files periodically.  I realize that is of little confort.  NSIT ans associated organizations should have been auditing services immediately after sensitive files were first discovered.

What is sad is that some organization in the administration just really did not get it... and was uploading files up to last week.

My theory is that the information originated from the registrar&#039;s office and was placed on krypton in order to transfer the information from one office to another within the administration.  The perpetrators probably were not aware of the public nature of the server nor of the inherent insecurity.

I optimistically hope that the Good Guys (tm) found it first and that the current situation will make people more aware of the sensitivity of the data they handle.
</description>
		<content:encoded><![CDATA[<p>I&#8217;m not sure if this could really be called a &#8220;compromise&#8221; since there has been no &#8220;incident&#8221; (at the moment, no one is known to have stolen the data), but it is a severe security violation.</p>
<p>I&#8217;m glad that deligent Residential Computing staff found the information, but I do find it dubious that the information ended up on krypton in the first place.  I am disappointed as well that that would occur.</p>
<p>The window of opportunity has also been sporadic since Rescom people have combing through the files periodically.  I realize that is of little confort.  NSIT ans associated organizations should have been auditing services immediately after sensitive files were first discovered.</p>
<p>What is sad is that some organization in the administration just really did not get it&#8230; and was uploading files up to last week.</p>
<p>My theory is that the information originated from the registrar&#8217;s office and was placed on krypton in order to transfer the information from one office to another within the administration.  The perpetrators probably were not aware of the public nature of the server nor of the inherent insecurity.</p>
<p>I optimistically hope that the Good Guys &#8482; found it first and that the current situation will make people more aware of the sensitivity of the data they handle.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ali Ebrahim</title>
		<link>http://blog.ebrahim.org/2005/05/28/ssn-records-at-uchicago-compromised/comment-page-1/#comment-355</link>
		<dc:creator>Ali Ebrahim</dc:creator>
		<pubDate>Sat, 28 May 2005 16:26:02 +0000</pubDate>
		<guid isPermaLink="false">http://blog.ebrahim.org/2005/05/28/ssn-records-at-uchicago-compromised/#comment-355</guid>
		<description>To &quot;someone@uchicago.edu&quot;, you&#039;re quick to assume that I&#039;m laying the blame on &lt;a href=&quot;http://nsit.uchicago.edu/&quot; rel=&quot;nofollow&quot;&gt;NSIT&lt;/a&gt;. In fact, nowhere in my post did I blame NSIT for how this has been handled. When I talk about the &quot;university&quot;, I use it to refer to the careless entity who uploaded private data onto a publicly accessible server. Given my dealings with those at NSIT, I don&#039;t think there is anybody there who would be stupid enough to do this.

I said that the people at NSIT are good people, and I applauded their quick action. Ultimately, NSIT cannot be held responsible for what its users do. I think we are in agreement on this.

I remain disappointed with the organisation within UChicago who negligently stored this information on a publicly accessible server.
</description>
		<content:encoded><![CDATA[<p>To &#8220;someone@uchicago.edu&#8221;, you&#8217;re quick to assume that I&#8217;m laying the blame on <a href="http://nsit.uchicago.edu/" rel="nofollow">NSIT</a>. In fact, nowhere in my post did I blame NSIT for how this has been handled. When I talk about the &#8220;university&#8221;, I use it to refer to the careless entity who uploaded private data onto a publicly accessible server. Given my dealings with those at NSIT, I don&#8217;t think there is anybody there who would be stupid enough to do this.</p>
<p>I said that the people at NSIT are good people, and I applauded their quick action. Ultimately, NSIT cannot be held responsible for what its users do. I think we are in agreement on this.</p>
<p>I remain disappointed with the organisation within UChicago who negligently stored this information on a publicly accessible server.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Someone</title>
		<link>http://blog.ebrahim.org/2005/05/28/ssn-records-at-uchicago-compromised/comment-page-1/#comment-354</link>
		<dc:creator>Someone</dc:creator>
		<pubDate>Sat, 28 May 2005 15:54:18 +0000</pubDate>
		<guid isPermaLink="false">http://blog.ebrahim.org/2005/05/28/ssn-records-at-uchicago-compromised/#comment-354</guid>
		<description>This was not the fault of NSIT.  Krypton is not a secure server and the policy is clear: don&#039;t put up things that need to be secure!  Someone who had access to Krypton -- and that&#039;s a lot of people -- uploaded secure information and made it world readable.  As far as I know (contrary to the Maroon article) none of this information was available at any time directly from the internet.  At the least you needed access to Krypton.

If, say, OUSH uploaded your personal information to a web server run by AOL would you upset with the OUSH or AOL?  Everyone seems to be opting for the latter.
</description>
		<content:encoded><![CDATA[<p>This was not the fault of NSIT.  Krypton is not a secure server and the policy is clear: don&#8217;t put up things that need to be secure!  Someone who had access to Krypton &#8212; and that&#8217;s a lot of people &#8212; uploaded secure information and made it world readable.  As far as I know (contrary to the Maroon article) none of this information was available at any time directly from the internet.  At the least you needed access to Krypton.</p>
<p>If, say, OUSH uploaded your personal information to a web server run by AOL would you upset with the OUSH or AOL?  Everyone seems to be opting for the latter.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

