Why Security is Difficult in the EDU world

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 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.