Re: Data Classification: Legal criteria

[Gary Dobbins <dobbins () ND EDU>]

> From personal experience, I'd advise staying clear of middle-ground
catch-all classes.  Invariably, there end up data at one end or the
other of its spectrum.  This means you can't as cleanly tie a set of
controls to a classification.  It becomes like a bell curve, and it's
expensive to control all data in that huge central range the same way
the stuff at the top end of the middle class warrants.

We went from a 3-class model to a 4-class one.  It provides some
interesting benefits:

1) you get a "super-top-secret cone-of-silence" class at the high end,
into which you can toss all the stuff that requires extra-ordinary
controls like PCI, without unduly burdening the rest of your sensitive
data.
2) you get an "internal" (just above public) class that just means
"stuff that we won't freak about if spilled" (e.g. calendars and room
schedules)
3) you get a "sensitive" class where you can practice that "careful"
level of diligence you commonly think of around things like grades.
4) you can designate the top half (the top two classes) as "sensitive"
and refer to them in aggregate conveniently.

Also, just because something is regulated doesn't mean it requires
PCI-level handling.  Take FERPA for example.  That's why I'd avoid
having a "regulated" category, and just say in your policy that any
requirements specified by contractual or governmental regulation trumps,
regardless of [your] classification.



> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Brad Judy
> Sent: Tuesday, March 18, 2008 5:40 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Data Classification: Legal criteria
>
> The easiest (perhaps not best) way to define "internal" is to define
> the
> two extremes (public and confidential in your case) and then define
> "internal" as all data that does not fit either of the other two
> definitions.  Essentially, the extremes are well defined and the
> middle
> ground is a catch-all.
>
> The advantage of this approach is that there is no data that defies
> definition.  The problem with three concrete definitions is that there
> will always be something that doesn't meet one of the definitions.
>
> The hardest part of the above approach, which you alluded to, is a
> good
> definition for "public".
>
> Here is a link to our data classification definitions:
> https://www.cu.edu/policies/General/IT-Sec_InfoClassification_P.pdf
>
> Brad Judy
>
> IT Security Office
> University of Colorado at Boulder
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Basgen, Brian
> Sent: Tuesday, March 18, 2008 12:04 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: [SECURITY] Data Classification: Legal criteria
>
>
>  We are in the process of developing a data classification policy with
> three types: public, internal, and confidential.
>
>  The criteria or logic behind classifying confidential data is fairly
> easy: FERPA, GLBA, PCI, etc, requires the confidentiality of certain
> data types. Yet, I am not clear on the best external criteria to use
> for
> classification of internal data. Peer institutions, "best practices"
> is
> one thought, but I'm wondering what other objective criteria people
> have
> employed for the justification of making certain kinds of data
> internal
> as opposed to public. Let me know, thanks.
>
> ~~~~~~~~~~~~~~~~~~
> Brian Basgen
> Information Security
> Pima Community College