Re: IT Security in Higher Ed.

[randy marchany <marchany () VT EDU>]

I started responding to Lee Anne's post on "Security in Higher ED" and
it somehow turned into the thoughts below.

Just a basic observation on my part that's based only on my experience.

1. EDUs have 2 distinct and competing functions from a security viewpoint:

  a. Corporate Network - as much as we don't like to admit it, the
administrative business functions (Payroll, HR, Registrar, Grants,
Athletics, etc.) have the same security requirements as any
corporation. We are in the business of education. We have a product we
sell (an education). We aggressively compete for customers
(prospective students) at the academic, managerial and athletic
levels. Our org charts are similar to corporations (Board of
Visitor/Regents/Directors > President>VP, etc.). Corporations sponsor
stadiums, TV shows to market themselves. EDUs have football/basketball
teams :-). We have to deal with regulatory compliance with Federal,
state, local regulations and laws. This corporate function allows the
EDU to function as a business.

b. ISP - all of us have on-campus students who use our network for
basically whatever they want. In most cases, these are individually
owned machines. We provide a network service and get (at least we
should) out of the way except to ensure no hogging of network
resources. This is exactly what an ISP does. Researchers and faculty
can fall under this category as well. The main difference is that they
may use a mix of individually and university owned machines. This ISP
function allows the EDU to function as a "school" or "research lab".

There is a common set of security protocols/requirements that span
across both worlds. This forms the baseline security requirements of
your institution. The Corporate Network component, however, requires
more stringent controls and procedures. The successful EDUs (from a
security standpoint) are the ones who tailor their security
requirements to fit the particular function of the EDU. Both functions
need a common baseline security model. Sometimes, it makes no sense to
apply a more stringent requirement on the ISP side of the house. When
we carefully analyze WHY that requirement was imposed, we find that it
was most likely due to staff limitations. In other words, the "there
are more user than sysadmins to manage them" scenario which causes the
few (sysadmins) to impose tight controls in order to impose "order" on
the many (users). (hmmm...sounds like a government class...:-))

My experience has shown that if we fail to analyze the "actual"
security requirements of a particular function and create a security
paradigm that interferes with the business process, then we open
ourselves to security issues. In other words, the business process
wins. The "art" of building a successful security posture comes from
a) knowledge of the business process and how a security requirement
will impact that process b) tailoring both the business and security
processes to allow the job at hand to be completed c) getting the
backing from your Board of Vistors/Regents/Directors to provide staff
to perform these functions.


I now put on my flame-retardant suit :-).

Randy Marchany
VA Tech IT Security Office & Lab