<?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: Ethics and the on-Line Storage of Client Documents</title>
	<atom:link href="http://www.slaw.ca/2010/01/07/ethics-and-the-on-line-storage-of-client-documents/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.slaw.ca/2010/01/07/ethics-and-the-on-line-storage-of-client-documents/</link>
	<description>Canada&#039;s online legal magazine</description>
	<lastBuildDate>Thu, 09 Feb 2012 23:12:15 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Philip L. Franckel, Esq.</title>
		<link>http://www.slaw.ca/2010/01/07/ethics-and-the-on-line-storage-of-client-documents/comment-page-1/#comment-746785</link>
		<dc:creator>Philip L. Franckel, Esq.</dc:creator>
		<pubDate>Sat, 16 Oct 2010 03:36:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.slaw.ca/?p=16032#comment-746785</guid>
		<description>This is typical of lawyers at bar associations without knowledge of the subject for which they create rules, whether it be computer security or advertising.  When you create rules about computer security without knowing anything about computer security or about advertising without knowing anything about advertising, you end up with bad rules, ineffective rules, and unconstitutional rules.

I wonder what the purpose is of changing the names of the client folders when the PDF documents within the folder will reveal the names.  Also, I agree with Raj Goel that a requirement of using a PDF document is basically a requirement of using Adobe.  I have spent many hours searching for another application, but this is one area where I have not found a suitable open-source alternative or even a suitable private alternative to Adobe Acrobat.</description>
		<content:encoded><![CDATA[<p>This is typical of lawyers at bar associations without knowledge of the subject for which they create rules, whether it be computer security or advertising.  When you create rules about computer security without knowing anything about computer security or about advertising without knowing anything about advertising, you end up with bad rules, ineffective rules, and unconstitutional rules.</p>
<p>I wonder what the purpose is of changing the names of the client folders when the PDF documents within the folder will reveal the names.  Also, I agree with Raj Goel that a requirement of using a PDF document is basically a requirement of using Adobe.  I have spent many hours searching for another application, but this is one area where I have not found a suitable open-source alternative or even a suitable private alternative to Adobe Acrobat.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Raj Goel</title>
		<link>http://www.slaw.ca/2010/01/07/ethics-and-the-on-line-storage-of-client-documents/comment-page-1/#comment-713328</link>
		<dc:creator>Raj Goel</dc:creator>
		<pubDate>Tue, 12 Jan 2010 18:13:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.slaw.ca/?p=16032#comment-713328</guid>
		<description>I see the need for these guidelines - however, as presented above, they are dangerous and will create liabilities:

&lt;em&gt;Second, the lawyer would assign unique randomly generated alpha-numeric names and passwords to each online client folder. The folder names contain no information that could identify the client to which it belongs. The password would not be the same as the client folder name&lt;/em&gt;

Great - random-character filenames.  Either people won&#039;t use them, or they&#039;ll start creating tiny urls.  I worked on a medical project where the guidelines were similar.  Long, complex urls to prevent dictionary attacks.  Within 10 hours of alpha testing, the userbase switched to tiny-urls, which amplified the attack and created a bigger problem.  The project was hastily withdrawn and implemented after careful thought to security.

Security was built into the DNA of the application, not bolted on afterwards.

Secondly, this is even more dangerous:

&lt;em&gt;Third, all online client files would be converted to Adobe PDF (Portable Document Format) files and protected with another randomly generated unique alpha-numeric password.&lt;/em&gt;

A) Making any security recommendation vendor-specific is dangerous.  Vendors go out of business, get bought out, let products die.  

B) For most people PDF == Adobe Acrobat readers, which in itself has a severe security problems.  There&#039;s (still) an unpatched javascript flaws in the reader that malware writers are using to infect windows PCs.

B1) Recommending PDF as a standard is fine - FoxitPro, SumatraPDF, etc are all good readers, without the security issues inherent in Acrobat.

C) The password-protecion mechanisms built into most commercial software (Microsoft Office, Adobe, etc) are easily crackable.  Either the underlying cryptographic mechanism is weak, or the passwords are crackable via dictionary attacks.

There&#039;s a commercial MS Office, Zip, etc. password recovery tool where the vendor inserted a time-delay (10-30 seconds) just so the customers wouldn&#039;t panic at how fast the passwords were recovered/cracked.

Simply put, the guideline reinvents the wheel for information security, without referring to existing mechanisms and makes layman&#039;s mistakes when dealing with infosecurity.

HIPAA has great guidelines for storing and sharing information securely.  

PCI-DSS has specific guidelines and methodology for implementing a security architecture.

NIST has standards and guidelines for implementing good infosec programs.

In all cases, you reader an cobble something together on their own, download templates off the web or hire an expert.

Strangely enough, same things happens in law.  
- Read Nolo press
- Buy or download forms and templates (wills maker, anyone?)
- Hire an attorney.

Same rules apply here -- if your practice is small, and the revenues at stake are small, you can apply one-size-fits-all guidelines.  (e.g. download a wills template off the net, fill it out, give it to your heirs.  Never mind that your template was from California, you live in New York and the inheritance laws are just a wee bit difference).

If your practice is larger, then retaining an expert to advise/vet your approach is recommended. (e.g. write your own contract, or borrow someone else&#039;s, read it carefully, and have a good attorney review it for you).

If the revenues at stake are large enough (and only you can define what large enough means to you - though $3M is a good place to start at), then it&#039;s strongly recommended that you retain a security professional to understand the business requiements, and implement a solution that is cost-effective and scalable.

For example, the guidelines above do not address State Privacy Breach laws, which vary from state to state, or address intra-state clients.  The FTC has taken a lead on consumer privacy issues and for firms with clients in multiple states, paying attention to FTC guidelines is a good idea.</description>
		<content:encoded><![CDATA[<p>I see the need for these guidelines &#8211; however, as presented above, they are dangerous and will create liabilities:</p>
<p><em>Second, the lawyer would assign unique randomly generated alpha-numeric names and passwords to each online client folder. The folder names contain no information that could identify the client to which it belongs. The password would not be the same as the client folder name</em></p>
<p>Great &#8211; random-character filenames.  Either people won&#039;t use them, or they&#039;ll start creating tiny urls.  I worked on a medical project where the guidelines were similar.  Long, complex urls to prevent dictionary attacks.  Within 10 hours of alpha testing, the userbase switched to tiny-urls, which amplified the attack and created a bigger problem.  The project was hastily withdrawn and implemented after careful thought to security.</p>
<p>Security was built into the DNA of the application, not bolted on afterwards.</p>
<p>Secondly, this is even more dangerous:</p>
<p><em>Third, all online client files would be converted to Adobe PDF (Portable Document Format) files and protected with another randomly generated unique alpha-numeric password.</em></p>
<p>A) Making any security recommendation vendor-specific is dangerous.  Vendors go out of business, get bought out, let products die.  </p>
<p>B) For most people PDF == Adobe Acrobat readers, which in itself has a severe security problems.  There&#039;s (still) an unpatched javascript flaws in the reader that malware writers are using to infect windows PCs.</p>
<p>B1) Recommending PDF as a standard is fine &#8211; FoxitPro, SumatraPDF, etc are all good readers, without the security issues inherent in Acrobat.</p>
<p>C) The password-protecion mechanisms built into most commercial software (Microsoft Office, Adobe, etc) are easily crackable.  Either the underlying cryptographic mechanism is weak, or the passwords are crackable via dictionary attacks.</p>
<p>There&#039;s a commercial MS Office, Zip, etc. password recovery tool where the vendor inserted a time-delay (10-30 seconds) just so the customers wouldn&#039;t panic at how fast the passwords were recovered/cracked.</p>
<p>Simply put, the guideline reinvents the wheel for information security, without referring to existing mechanisms and makes layman&#039;s mistakes when dealing with infosecurity.</p>
<p>HIPAA has great guidelines for storing and sharing information securely.  </p>
<p>PCI-DSS has specific guidelines and methodology for implementing a security architecture.</p>
<p>NIST has standards and guidelines for implementing good infosec programs.</p>
<p>In all cases, you reader an cobble something together on their own, download templates off the web or hire an expert.</p>
<p>Strangely enough, same things happens in law.<br />
- Read Nolo press<br />
- Buy or download forms and templates (wills maker, anyone?)<br />
- Hire an attorney.</p>
<p>Same rules apply here &#8212; if your practice is small, and the revenues at stake are small, you can apply one-size-fits-all guidelines.  (e.g. download a wills template off the net, fill it out, give it to your heirs.  Never mind that your template was from California, you live in New York and the inheritance laws are just a wee bit difference).</p>
<p>If your practice is larger, then retaining an expert to advise/vet your approach is recommended. (e.g. write your own contract, or borrow someone else&#039;s, read it carefully, and have a good attorney review it for you).</p>
<p>If the revenues at stake are large enough (and only you can define what large enough means to you &#8211; though $3M is a good place to start at), then it&#039;s strongly recommended that you retain a security professional to understand the business requiements, and implement a solution that is cost-effective and scalable.</p>
<p>For example, the guidelines above do not address State Privacy Breach laws, which vary from state to state, or address intra-state clients.  The FTC has taken a lead on consumer privacy issues and for firms with clients in multiple states, paying attention to FTC guidelines is a good idea.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Dundas</title>
		<link>http://www.slaw.ca/2010/01/07/ethics-and-the-on-line-storage-of-client-documents/comment-page-1/#comment-710161</link>
		<dc:creator>Michael Dundas</dc:creator>
		<pubDate>Thu, 07 Jan 2010 22:11:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.slaw.ca/?p=16032#comment-710161</guid>
		<description>I am glad this topic for law firms is being discussed.  It needs to be.  In consulting in the past, I was amazed at the lack of security that law firms deploy.  Don&#039;t get me wrong, they are no worse than other companies, but I was surprised when I first started.  I expected them to be more concerned about it than the average business given the sensitive nature some of the information holds.  

Hope this discussion keeps up.
-mike.</description>
		<content:encoded><![CDATA[<p>I am glad this topic for law firms is being discussed.  It needs to be.  In consulting in the past, I was amazed at the lack of security that law firms deploy.  Don&#039;t get me wrong, they are no worse than other companies, but I was surprised when I first started.  I expected them to be more concerned about it than the average business given the sensitive nature some of the information holds.  </p>
<p>Hope this discussion keeps up.<br />
-mike.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- This Quick Cache file was built for (  www.slaw.ca/2010/01/07/ethics-and-the-on-line-storage-of-client-documents/feed/ ) in 0.35536 seconds, on Feb 10th, 2012 at 1:21 am UTC. -->
<!-- This Quick Cache file will automatically expire ( and be re-built automatically ) on Feb 10th, 2012 at 2:21 am UTC -->
