The Challenges of Securing University Computer Networks | Hacker News Reader

The Challenges of Securing University Computer Networks

theatlantic.com

26 pointsherendin14 comments

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.

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.

I totally believe that university password requirements are the strictest. The general standards for a "strict" password are >N characters, 3 of 4 character classes required, and sometimes a blacklist of passwords.

The standards for my university? The ones I figured out (they don't spell a guideline out for you until you violate it): * >N characters * 3 of 4 classes * No substring of >5 characters can match a dictionary word (which apparently includes "anita" o_O) * Can't have your name in there anywhere * No three consecutive characters can be the same or a run (so no 111, 123, 321, ghi, etc.) * Can't be any of your last 10 passwords * Please change every 9 months

There's probably a few more that I haven't had cause to discover yet.

Source on that statement about expensive password policies please?

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

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

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.

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.

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

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

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

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.

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

Surprised there was no mention of eduroam: https://www.eduroam.us

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.

Reply on news.ycombinator.com