[ISM3 Users] Tuesday Insight - Blast from the Past - Information Classification

[Vicente Aceituno]

Updated and summarized post
****Implementation Plan****originally posted Jul 24, 2006 9:47 am***
Choosing the optimum protection for an information system becomes easy
when one can determine what needs to be protected.

ISM3's  Security in Context and IAML can be used for detailed
information system classification, in a way that is compatible with
using the old Confidenciality, Integrity, Availability.

ISM3 uses the following classes. IAML is a language that enables the
implementation of this classification in applications.

-Secrecy (e.g protectiveMarking="Internal")
Secrecy is kept using access control and user registation techniques.

-Privacy (e.g privacyMarking="Private")
Privacy is kept using anonimization, access control and user
registation techniques.

-Licensing (e.g objectLocation="Spain",  policySet="X Software
License", startDate, expiryDate, constituency="Europe",
securityHandling="Licensed", handlingControl="Access Control",
handlingApplicability="Mandatory")
Licensing is kept using access control and user registation techniques.

-Intellectual Property (e.g objectLocation="UK",  policySet="Patent",
startDate, expiryDate, constituency="Europe",
securityHandling="Licensed", handlingControl="DRM",
handlingApplicability="Mandatory")
Intellectual Property is kept using access control, user registation
and digital rights management techniques.

-Availability (e.g availabilityMarking="High", startFirstWindow,
endFirstWindow, recurringPeriod, recurringCardinality,
minPercentageUptime, maxNumberOfInterruptions,
maxNumberOfTransactionsLostPerInterruption, minLoad, loadUnits,
businesscontinuityMarking="Critical" ,recoveryTimeObjective,
recoveryPointObjective)
Availability is kept using backup and redundancy techniques.

-Retention period (e.g  retentionTarget, integrityMarking,
retentionEvent ,retentionEventDate, minRetentionSinceRetentionEvent,
maxPercentageOfItemsLost)
Retention is met using archival techniques.

-Expiry (e.g  expirationTarget, expirationEvent, expirationEventDate,
maxRetentionSinceExpirationEvent)
Expiry is kept using safe deletion techniques.

-Completeness (e.g. maxNumberOfUnnecessaryItems ,
maxPercentageOfEmptyItems, maxPercentageOfMissingItems,
maxPercentageOfIncoherentItems)
Completeness is achieved using business-dependent techniques.

-Accuracy and Relevance (e.g. precisionTarget,
maxPercentageOfIncorrectItems, relevanceTarget,
maxPercentageOfOutDatedItems, averageRelevanceOfItems)
Accuracy and Relevance is achieved using business-dependent techniques.

Please note both ISM3 and IAML support and highlight *Access Control*,
as a mean to achieve security objectives, and *Compliance*, as both a
mean to achieve security objectives and a security objective on its
own.

My best

Vicente

*********************
Gray Hinson said:

Ah, OK Vicente.

I agree there are several other important characteristics of
information besides confidentiality, and that these aspects need to be
taken into account in designing controls for specific items of
information or information systems. Does this actually help with
classification, though? It's easy to get too granular in your
analysis, meaning too many categories and, in the extreme, categories
with only one item each, which rather
defeats the object of classification.

Classification is a way of putting related things into categories or
classes, grouping together 'similar things' with the implication that
common controls apply to all items in each class. For a simple
example, your "criticality" could be a binary classification:
"critical" or
"non-critical". This implies that controls needed to protect
"critical" information can be differentiated from those needed for
"non-critical" information. In practice, "criticality" is defined
quite loosely if at all in organizations I've worked for. It generally
means "importance" but importance, like beauty, depends on the eye of
the beholder i.e. what is
important to one manager (or customer or auditor ...) is not important
to another. Even something as simple as defining business-critical
processes, along with the information and IT systems supporting them,
is no mean feat. The Research & Development department in an average
organization could claim that it is business-critical because if there
is no R&D taking place, the company's future market position and hence
survival is threatened. Compared to Operations, Finance etc., however,
R&D failure causes second- or third-order impacts whereas Ops or
Finance failures cause immediate survival issues.

Even if we agree on the criticality classification of R&D as a whole,
there are elements of R&D at either end of the scale - research
programs with no hope of commercialization at the bottom end and
patentable inventions at the other.

Some of those patentable inventions may have tremendous commercial
prospects, others less so.

... And so on. Until eventually we decide that we need to encrypt the
data file containing lab results from Project X but not those from
Project Y - at which point, we probably have categories with one item
each.

I know I'm reducing your argument to the extreme but I'd just like to
make the point that excessively fine or granular classification is as
bad as the excessively broad.

G.


Dr Gary Hinson PhD CISSP CISM CISA MBA
CEO, IsecT Ltd.
www.NoticeBored.com - a fresh approach to security awareness
www.isect.com - security consulting and ISO 17799 policies
www.ISO27001security.com - discover the new ISO security standards
www.GlobalSecurityWeek.com - start planning now for September 4-10th