
The Challenges of Securing University Computer Networks - herendin
http://www.theatlantic.com/technology/archive/2015/10/can-campus-networks-ever-be-secure/409813/?single_page=true
======
analog31
_Universities are struggling to find balance between academic openness and the
need for computer security across their networks._

Let's not forget cheapness. Perhaps a major issue is that most of the
"academic have nots" are expected to buy their own computers and software.
Disclaimer: My spouse is such a worker. As a result, there's a proliferation
of computers on the academic network, with varying levels of security
installed, and no incentive to secure them further.

My spouse's attitude is pretty typical: If they want security, they can buy
her a computer, otherwise it's her personal property and they're not allowed
to touch it. The research labs are off limits to the IT staff because
"updates" cause old computers running lab equipment to stop working.

------
jldugger
Universities are generally designed such that people following their natural
incentives will get security wrong. Universities tend to have both central
staff, and departmental IT staff distributed amongst them. It works in the
sense that departments with larger needs can fund their own hires, but they're
often understaffed, underfunded, and report to (and are hired by) people who's
general requirements are that systems operate either long enough to submit a
grant proposal, publish a paper, lecture in front of class or submit final
grades. Anything security related, like rolling out patches, is likely to
interfere. This hypothetical won't fly:

> 'Oh gee, we rolled out the latest version of firefox and now your lab's
> instructional java applet won't run. Sorry we didn't test that before going
> live. But we patched this weeks' bug. See you this time next week!'

I figure until cybersecurity causes more outages than security lapses, the
departmental system will continue to underinvest in security practices and
overproduce botnets.

Because of that division, central IT folks working in security have few levers
they can pull or dials they can twist. It's been shown that universities have
the most expensive password policies among policies observed. Think about
that: you can execute a six figure trade using a password less secure than
what you need to download a lecture video in Blackboard.

~~~
newman314
Source on that statement about expensive password policies please?

~~~
jldugger
Did you search at all because you were interested in the research, or were you
just hoping to call that out as bullshit? Let's pretend for a moment you're
genuinely curious.

Florêncio & Herley of Microsoft research published a paper: Where do security
policies come from?
[http://dl.acm.org/citation.cfm?id=1837124](http://dl.acm.org/citation.cfm?id=1837124).
Their finding demonstrates that uni policies require more entropy.

Cormac has done a lot of research on the subject of passwords, including a
recent survey of the subject presented to usenix:
[https://www.usenix.org/system/files/conference/lisa14/lisa14...](https://www.usenix.org/system/files/conference/lisa14/lisa14-paper-
florencio.pdf)

Kelley et all at CMU used a mechanical turk study to collect a large set of
passwords under different policies, and observe error rates, and password
recovery requests. While they found that some policies were more effective at
recall than others, the general trend is more entropy -> less recalled.

Finally, experience. I worked as a programmer at a university, where I saw how
this plays out: Internally, tickets are assigned a root cause; password resets
were assigned to IDM, even though the system was working as requested.
Helpdesks are typically 50-75 percent password reset, so we looked far worse
than the rest of the teams. The Helpdesk manager is responsible for staffing
helpdesk, but has no say on security policies. The CISO has limited budget,
but can set policies. Our Identity Management software development team,
responsible for enforcing password strength policies, password expiration
notices, directory information, etc., met with both of these people regularly,
and it became clear they did not.

As Cormac points out, it's likely that .com policies are simpler, because they
have to attract and retain customers. It seems likely .com measures bounce
rates for signups, and universities that have an adwords campaign had policies
closer to .com than .edu. I forget if we measured bounce rates, but we did
implement a system to track how many tries it took for people to produce a
valid password. This was a while ago, and I switched to server administration
shortly after this, but I recall the statistics being roughly an average of 2
tries, maybe more. Meanwhile, the security team actually ding'd us for
providing a realtime feedback of whether the password field was or was not in
the dictionary, in line with the rest of the real time policy checkers they
requested (3 of 4 character categories, 9 characters long, etc).

------
superuser2
My university doesn't really have a concept of "The Network" being privileged
or sensitive. It's just a route to the internet, like any other utility ISP.
There's 802.1x authentication with your SSO credentials (both wired and
wireless with WPA2 enterprise), so your actions are accountable, and if you're
doing botnet/spam/blackhat things they can cut you off and come find you. WPA2
enterprise uses a certificate to authenticate the AP to the client, so pirate
WiFi isn't a security issue either, just an interference problem.

Services are all exposed to the internet (mostly as webapps) with Shibboleth
CAS/SSO authentication. The only thing you need "The Network" for is IP
whitelisting for journals. There's a web proxy you can use for that if you're
off campus. We also have a separate guest SSID that's routed through non-
whitelisted IPs.

We have a distinction between "Managed Computer" and "other," where Managed
Computers are required for data that's confidential or subject to regulation.
I'm sure there are Managed Computers in finance/payroll/scary labs but your
average professor or student doesn't need one.

------
windowsworkstoo
Having spent a lot of time in this domain, you have to (and most seem to be
coming to the same conclusion) just assume that everything that connects to
your network is untrusted and likely owned and work inwards from there for
your threat modelling.

You have to really forget about trying to secure the client (and this includes
campus supplied gear) and up your monitoring game.

ISTR that Google has also taken a similar approach with its employees access
to their LAN.

~~~
jesseendahl
+1 to not trusting your network (or any network), but that doesn't mean you
should give up on securing your clients if you have control over them (e.g. in
a corporate environment). FWIW Google certainly does not ignore client
security. They do assume that all networks are untrusted.

"Google’s BeyondCorp initiative is moving to a new model that dispenses with a
privileged corporate network. Instead, access depends solely on device and
user credentials, regardless of a user’s network location—be it an enterprise
location, a home network, or a hotel or coffee shop."

"BeyondCorp uses the concept of a “managed device,” which is a device that is
procured and actively managed by the enterprise. Only managed devices can
access corporate applications."

[http://static.googleusercontent.com/media/research.google.co...](http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43231.pdf)

~~~
windowsworkstoo
Sure, BeyondCorp is what I was thinking of. And yes, there are a subset of
devices that are managed and can be used to access higher levels of "security"
but these are deliberately limited so they can be managed closely.

But the underlying point was that the default position is untrusted network,
untrusted clients - even for the vast majority of clients that you would
otherwise consider "managed" \- eg classroom computers, laptop trolleys etc

------
omnibrain
That's similar to the issued the IT administration of the german Bundestag
faced when parts of their network got owned.

I think not seeing it as "one network" but instead of seeing it as an internet
in which some instances offer services for other instances helps. The "one"
network is prone to fail because in such an environment you can't fit all
parties under one hat. (And perimeter security is dead, anyway.)

------
bro-stick
BTDTBTTS. I was forced to "resign" a sysadmin 4P3 FTE job at Stanford because
I refused to sign off a vendor's rushed and unreviewed demand to likely weaken
the security of well-planned credit-card processing private network. That's
after we successfully lobbied the university to have departmental firewalls of
networks, especially those connecting admin staff computers, which were
previously directly on the internet with routable IPs and very little
filtering... often found to be serving malware and dumpsites. There was even a
gal from Shmoo brought in to make change, but was unable to due to
institutional resistance. Later on, a laptop went "missing" with all staff
social security numbers because of the failed ITS mantra of "security is
everyone's responsibility [and therefore no ones, because it's allowed to
become a preventable Tragedy of the Commons]." There were next to no concrete,
practical standards (apart from ostensible and vague policies) for securing
Windows, Linux, etc. and every pocket of IT did their own thing, without any
sort of minimum standard of rigor.

Let's not also bring up how vendors were allowed to supervise and set vague
plans for themselves, waste millions of dollars on many projects, at numerous
levels, and not have any material results to show for it. They had these
vendors sitting on-site coding away for a couple years on some zombie project,
still getting paid to do almost nothing, because it would too embarrassing to
admit it was mismanaged and a total failure.

Students had no clue how I had access to all of their personal data, including
the VIP pseudonym database and the housing draw, which was running on a Linux
minitower which sat behind me. As a joke, a coworker and I ran Nessus against
it and found all sorts of unpatched vulerabilities which could be used to gain
root access to it... it was cluster-fuck that the admin didn't want to deal
with and pretended was fine.

Running academic computing networks is balancing openness and freedom with the
routine tasks and security costs of cleaning up owned computers... we observed
unpatched machines owned in anywhere in as little as 17 to 30 seconds, with a
mean average of about 25 but no longer than about 2 minutes. The most
important thing for campus IT: it needs to be kept to high standarda of
professionalism, without being run like either a profit-centric corporation#
or a small-town school district.

Note: the housing and dining dept (R&DE), is part of Budgets and Auxilliaries,
which is code for one of the largest profit-center, cash-cows of the whole
unversity... to the tune of a quarter of a billion dollars. So if you ever
wondered why drinks were so expensive in Tresidder or why the dining hall food
used such cheap ingredients, it's because it's a business, not a center for
learning.

~~~
selimthegrim
So whose idea was that Sophos albatross I had to reinstall every time I set
foot on campus for a visit?

------
thinkmoore
Surprised there was no mention of eduroam:
[https://www.eduroam.us](https://www.eduroam.us)

~~~
windowsworkstoo
Why? It doesn't really address any of the issues raised, it's just another
system to support and another source of potentially bad clients.

