Re: Security metrics for small and community colleges

[Jim Dillon <Jim.Dillon () CUSYS EDU>]

Some comments inline.

JD
*****************************************
Jim Dillon, CISA, CISSP
IT Audit Manager, CU Internal Audit
jim.dillon () cusys edu
303-492-9734
*****************************************
  
-----Original Message-----
From: Mark Morrissey [mailto:mark.morrissey15 () PCC EDU] 
Sent: Monday, May 21, 2007 10:13 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] Security metrics for small and community colleges

Let me preface this by saying that it is my assumption that small
colleges
and community colleges have fewer staff and other resources for
developing,
analyzing and reporting security metrics (perhaps IT metrics of any
kind).
If I am wrong in that assumption, please accept my apologies.

<< I think you are wrong, but on a slightly different track.  The basic
principles of Confidentiality, Integrity, and Availability are immune to
size, they are representative of criticality and privacy/sensitivity
these days as much as anything else.  No matter your size, critical
systems must be supported as critical systems should, and privacy is no
less a demand of your customers. Perhaps your variety is smaller, your
touch-points fewer, but criticality and objectives rule nonetheless.

I see the big difference in small vs. big as being less inertia towards
distributed computing and the unmanaged nightmare the larger/wealthier
institutions get into.  There is less argument for autonomy, less
support for "sufficiency of skills", more visibility in a smaller
environment, and thus I think an advantage should you choose to use it
in creating a secure shared infrastructure.  The key is sharing an
understanding of criticality and privacy/sensitivity.  Any other excuse
is simply not living up to the business requirements necessary to
support your infrastructure.  Note I said business requirements, not IT
requirements.  (This is ignoring the very real possibility that
management has totally underestimated the IT infrastructure requirement
due to less IT knowledge in the C-Suite.)  JD->>

I am relatively new to my institution and am bringing the information
security program up from scratch. As I start this program, it is clear
that
we will need to baseline our security posture so as to be able to
measure
and report both the effect of infrastructure changes on the security
posture, and report out to various stake holders the state of
information
security in a manner that is meaningful to them.

At the recent EDUCAUSE Sec '07, there was a great presentation on
security
metrics by Matt Tolbert (UPitt) and a great session on reporting by
Kathy
Bergsma (UFlorida) and Joshua Beeman (UPenn). It is clear from these
presentations, talks with other institutions, and discussions within my
own
institution that a small group of (potentially derived) metrics,
tailored to
each stake holder group, is needed. Being new to infosec in the small
and
community college arena, I am asking for assistance.

<< I won't speak here, you've had some good input I think.  JD->>

How are similar small and community colleges organizing their metrics
gathering and reporting for information security? What are your
principle
stake holder groups and what infrastructure have you rolled out to
support
reporting to these groups? Also, how are you using your metrics to show
compliance with applicable federal, state, local, and institutional
rules
and regulations?

<< Again, I won't speak to the metrics end, there are others better
suited, but I will speak to the foundation supporting the metrics. 

1. Clear definition of asset value - both from a sensitivity and a
criticality stance is key.  No steward/custodian/owner should be unclear
about what makes something critical or sensitive.
2. Clear responsibility - if you provide a service and there is an
impact or potential impact on your own or your neighbors critical and
sensitive items, you are responsible to mitigate the risk and
responsible for the consequences.
3. Upper management devotion to the above - enough so that they follow
through on the responsibility end and assign the cost to the infringing
parties, publicly, quickly, and consistently.
4. An accurate inventory of all systems, with critical and sensitive
stores/processes/flows/creation clearly identified.
5. Criticality determination is not the job of the IT department, it is
the responsibility of management.  If senior management has not clearly
endorsed its objectives, and conducted risk assessment/business impact
analysis on its IT assets, you have very little chance of optimizing
your metric or your operations, you are only guessing.  You must have
management buy in on what is critical or sensitive or you cannot
properly distribute your efforts.

Whatever your metrics are, they should be supportive of the above I
think.  In this manner you can align your work to the goals and
objectives of the institution.  Lots of things can be measure, measure
what is most important to YOUR institution.  JD->>

That looks like a good start  :-)

Thank you in advance for your help.  Please, if you send me email
directly,
let me know if I can share your information in a summary on this topic.
I
always like to summarize my findings back to where I asked for help.

<<Mark, the above are the musings of an IT Auditor, not an experienced
operational manager (salt required), but they reflect all of what I've
observed both as a member of the IT community and as an auditor in
commendable practice and practical risk based reasoning over the last 19
years or so.  Bounce the feedback you get off these suppositions against
your more operational input, and I think you'll find a good balance.
Your metrics need to support YOUR objectives.  Often operational
feedback is so bound by the realities of limitations in resources and
support that I think it misses some of the thematic/principled
underpinnings of business objective and risk.  All profit is achieved by
some degree of risk, and there is a limit where risk becomes
intolerable.  You must find that crossing point to be optimally
organized.  Typically management does not give enough consideration to
this problem and they treat IT as a commodity, not recognizing the many
tangible and intangible assets that underlie their information
architecture.  My perspective is slightly more purist and perhaps a tad
unrealistic given the norms of the "real world", but I'd sure shoot for
it if I could.  Good luck.  I welcome your comments.  JD->>


--mark
-----------------------
Mark Morrissey
Information Security Manager
Portland Community College, Portland, Oregon
mark.morrissey15 () pcc edu
Desk: 503-977-4896  Mobile: 503-969-5631