[Owasp-portland] Owasp-portland Digest, Vol 13, Issue 1

Mel Drews meld at infoatrisk.com
Sun Feb 6 11:42:33 EST 2011

My company primarily works at assisting organizations to comply with
regulations such as GLB, SOX, HIPAA and NERC.  And so, we were very
interested when we saw Oregon pass data breach notification legislation.
 But what we've seen over the years is that organizations tend to pay
little attention to such things until it starts costing them money or
puts them at serious risk of loss.

Gramm-Leach-Bliley is proactively enforced.  But at first the examiners
didn't really have much knowledge of what they were looking for and the
industry norms were so poor that it was years before the financial
services organizations to which it applies really got serious about
implementing information security controls.

Sarbanes-Oxley was taken a bit more seriously right away because it
calls for strict accountability by the CEO.  But it only applies
directly to systems used in financial reporting and is more focused on
integrity rather than confidentiality.  So, I don't think the impact is
very large in terms of creating much actual security.  It helps.

NERC started out years ago with a bunch of standards that weren't really
enforced very proactively and didn't apply to many utilities.  Congress
changed that and FERC has been good about pushing the industry.  But it
wasn't until they were threatened with big fines that most utilities
started put serious resources toward security.

The same is true for HIPAA.  Large organizations have realized that they
want to stay out of the headlines and avoid fines.  There have also been
a few significantly publicized data breaches and fines handed out under
HIPAA.  The bulk of covered entities, however, still don't really have
their act together, from my perspective.  This is because there has been
no proactive enforcement in the past; it's only been complaint driven.
HITECH, integrated with ARRA changes that a bit, calling for proactive
audits, but we don't know yet how that will be implemented.

Given this history, I expect little to nothing to be done by businesses
to comply with Oregon (or any other state's) data breach notification
statutes until they start seeing their peers getting some significant
fines handed down and loosing business due to the publicity of breaches.
 Perhaps at some point the cost to comply will be less than the various
risks of getting caught with your pants down on this.

On 02/06/2011 09:00 AM, owasp-portland-request at lists.owasp.org wrote:
> Send Owasp-portland mailing list submissions to
> 	owasp-portland at lists.owasp.org
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.owasp.org/mailman/listinfo/owasp-portland
> or, via email, send a message with subject or body 'help' to
> 	owasp-portland-request at lists.owasp.org
> You can reach the person managing the list at
> 	owasp-portland-owner at lists.owasp.org
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Owasp-portland digest..."
> Today's Topics:
>    1. Re: ORS 646A (James C. Bohem)
> ----------------------------------------------------------------------
> Message: 1
> Date: Sat, 5 Feb 2011 14:11:41 -0800
> From: "James C. Bohem" <james at holycow.portland.or.us>
> Subject: Re: [Owasp-portland] ORS 646A
> To: "Timothy D. Morgan" <tmorgan-owasp at vsecurity.com>,
> 	owasp-portland at lists.owasp.org
> Message-ID: <1110205141141.ZM14342 at holycow.portland.or.us>
> Content-Type: text/plain; charset=us-ascii
> On Jan 21, 10:33am, Timothy D. Morgan wrote:
> } Subject: [Owasp-portland] ORS 646A
> } Hi Everyone,
> } 
> } I thought I'd break the silence and see if anyone has any experience
> } with this trade regulation.  For "fun" I was just reading through the
> } Oregon statutes related to information disclosure and was surprised to
> } find some relatively strong language around information security
> } programs.  I'm looking here:
> } 
> }   http://www.leg.state.or.us/ors/646a.html
> } 
> } The 646A.600 section is relevant, and in particular, I find 646A.622
> } intriguing, since it applies to just about any organization.  Does
> } anyone have experience with how this section is interpreted for various
> } sizes of businesses?
> } 
> } tim
> } 
> Not expereince with interpretation, since the law isn't that old, but I went
> to a discussion of this statute soon after it became law. It is basically
> Oregon's state privacy law, loosely modeled after California's SB1386, and others.
> Somewhere around here, I have some guidance from the state on how they intended
> to apply this roughly 2 years ago. I'll dig it up. 
> The intent is that it does apply to just about everyone, and like most of the
> first generation state privacy laws, isn't very prescriptive about how you
> comply. For more granular, second generation state laws, look at what has been
> passed in MA, MN, and NV in the last year or so; there's lots more detail 
> about safeguards and requirements; NV's goes as far as to mandate an approach
> modeled on PCI-DSS for personal information. 
> My expectation is that the safeguards listed in section 622 are going to
> get argued in court as due care issues; you should be able to demonstrate 
> that with evidence of comliance to GLBA or HIPAA, as stated. Any of PCI-DSS,
> ISO, NIST, COBIT, ITIL... or a solid InfoSec program or your own creation
> could also suffice. It will be a up to lawyers and expert witnesses
> to argue whether 622 is met or not when this gets applied to a breach.
> Here's one example where the statute was used to coerce a settlement:
> http://clientdatasecurity.com/Oregon-Spruill-Order.pdf
> I'm not aware of much else generating press on this statute.
> James
> ------------------------------
> _______________________________________________
> Owasp-portland mailing list
> Owasp-portland at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-portland
> End of Owasp-portland Digest, Vol 13, Issue 1
> *********************************************

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
Url : https://lists.owasp.org/pipermail/owasp-portland/attachments/20110206/30dbacb4/attachment.bin 

More information about the Owasp-portland mailing list