hackers-colleges-universities

Why colleges and universities are easy targets for hackers–and what to do about it


Unrestricted access demanded by students is luring hackers to higher education networks. But what can IT do?

The complexity of College campus computer networks combined with the number of users and the need for unrestrained access, opens the door for hackers to try their skills. Unlike business owners who can make decisions on what is and isn’t blocked from the internet, colleges and universities must operate a bit differently.

These schools in many cases are essentially internet service providers for their students who access very few resources on the local network. Almost every web site they visit and email they receive is from a source that resides outside the LAN.

Students Demand Unfettered Access

Because students are often paying hefty tuitions, they generally want unfettered access to anything on the internet.  Although much of the traffic they create is non-academic related, the argument is that any blocking could inhibit their learning and research efforts.  To add to the security problem, many young adults stay plugged into social media during all hours of the day.  Even when sitting in their classes they can be found texting, tweeting and making comments on Snapchat and Facebook.  All of these communications add up to a massive amount of short, quick connections to the internet which need to be evaluated for security reasons.

When young adults aren’t on social media, the programs they are running on their personal devices are constantly uploading details about their devices, unbeknownst to many students.  In truth, many applications today are providing free use of their application in exchange for the right to take information from the student’s device.  Software such as Windows 10 and Pokémon Go for example, are frequently uploading information about the devices they are installed on.  This causes additional internet traffic which exacerbates the connection volume that university security is partially responsible for.

(Next page: Where the traffic is going and how to gain visibility to prevent hackers)

Where Is All of This Traffic Going?

Years ago, the network team could identify the application causing the traffic under surveillance by either looking at the source and destination TCP ports being used or the internet domain behind the IP address involved.  Later on, vendors performed something called Deep Packet Inspection (DPI) where they would look deeper into the packet’s payload and even observe a series of packets to identify applications.  It even worked with difficult-to-identify peer-to-peer applications such as Skype, but it didn’t work for long.

Today, these strategies don’t work nearly as well because of primarily two reasons:

1. Content delivery networks: Lots of traffic today is headed for internet sites such as Amazon AWS, Akamai or PubNub.  Both Microsoft and Adobe software updates use these services as well as Netflix.  As a result, when security administrators observe traffic to one of these sites, they can’t determine if the traffic is work related or personal in nature. This is frustrating and more importantly, administrators can’t stop it. In fact, the same IP address managed by Akamai Technologies could be hosting work and non-work related content. Administrators can’t tell the difference using DPI because of the second issue: encryption!

2. Encryption: Over two years ago, Google announced that they would play SEO favorites to websites that implement secure connectivity (e.g. HTTPS) on their web sites.  Since then, companies have been quick to implement SSL or TLS in order to comply.  Over 70 percent of internet traffic today is encrypted and as a result, DPI stopped working…but not for long.  SSL DPI was introduced which performs a Man in the Middle (MITM) on the certificate exchange.  Although MITM is often associated with hacking, it is also utilized by ethical vendors in order to regain visibility into encrypted connections. However, the problem with SSL DPI is threefold:

  • It requires a configuration change on every web browser.  If the application isn’t browser based, it won’t be accessing the internet.
  • In some countries (e.g. Germany) it can cause legal issues surrounding privacy. In the US, it is a violation of some medical compliance regulations.  As a result, exclusions must apply.
  • It can place a lot of processing overhead on the security appliances responsible for performing it.  Often times, it has to be turned off due to unacceptably slow connections.

Students simply won’t tolerate slow connections!  They also don’t like their privacy being invaded unless of course it means they can’t play Pokémon Go.  : )

Visibility into Encrypted Traffic

There is a way to regain visibility into encrypted traffic that doesn’t trigger privacy issues or cause performance degradation—it involves gathering context.

If the security team is investigating a suspicious IP address, they will want additional context such as the username (e.g. hclinton) that authenticated the device onto the network. Security administrators will also want to identify the type of device (e.g. iPhone) as well as details surrounding the internet IP address users were visiting such as the website (e.g. Netflix.com).  As a result, the context surrounding a device involved with an incident can tell us, for example, that when the incident occurred the user hclinton was visiting Netflix.com from her iPhone.  Clearly these details make trouble shooting much easier. Here is how the context is gathered:

  • Usernames can be gathered from the Microsoft domain servers or from other vendor products such as Cisco ISE or ForeScout’s CounterACT.
  • Device types can be gathered from Cisco ISE, CounterACT or sometimes just by looking at the MAC address of the device.
  • Internet site or 2nd / 3rd level domain requested is obtained by watching the DNS requests.  For example, the device that requested the IP address for the domain Netflix.com.  The DNS responded with an IP address for Akamai Technologies.

Most universities are collecting some or all of the above data.  The security team simply needs to cross reference it with the NetFlow or IPFIX collected from the existing routers and switches that are supporting the students. Examples are shown below.

usernames

Picture2

With all of this unrestricted access, students who enjoy clicking, joining and reading are bound to introduce malware to their devices and eventually onto the internal campus network.  Once inside, the malware can much more easily infect other internal users.  Infections can move laterally inside a network fairly easily because many security administrators are focused on two things: Outbound internet traffic and access to internal resources.

The nastiest intrusions easily sneak past the best firewalls and antivirus solutions. As a result, security teams are now focusing more on monitoring for odd communication behaviors internally before they access the internet.  Examples of this include:

  • comparing the volume of unique connections vs. destinations
  • counting failed DNS lookups and NX domain replies
  • triggering for fully qualified domain names that look like encrypted messages
  • checking the reputation of the domain reached out to
  • monitoring large “low and slow” data transfers between non server devices

Once a behavior triggers an event like the above, context surrounding the perpetrator becomes important for speedy investigations.  The better the context, the faster the security team can be with Malware Incident Response.  The next time an infection is suspected, tracing the event back to the source is much quicker.  When an RIAA notice is received, finding the student who participated in pirating a movie is a snap. So remember: Having context readily available is key.

Sign up for our newsletter

Newsletter: Innovations in K12 Education
By submitting your information, you agree to our Terms & Conditions and Privacy Policy.

eSchool Media Contributors

Sign up for our newsletter

Newsletter: Innovations in K12 Education
By submitting your information, you agree to our Terms & Conditions and Privacy Policy.