Aller au contenu principal

L'Université Trent réduit de 80 à 90% les utilisateurs touchés par le phishing grâce au pare-feu DNS D-Zone (en Anglais)



Interview with Andrew Bell, Manager, Digital Services Delivery and Administration at Trent University.

What is the role of your team in supporting the organization?

Trent University is a mid-sized Canadian university with two campuses in Peterborough and Oshawa. The user base includes around 1,600 staff and 7,000 students. My team makes up about one quarter of the total 30 IT staff and our role is to manage the digital infrastructure. We joke that, “if it has wires then it belongs to us.” The technologies we manage include networking, servers and telephony - we are not involved in desktop support, although we do work closely with that group to ensure our systems integrate effectively.

What are some of your big focus areas?

We recently upgraded most of our network, so the hardware focus for the next year or so is on leverage that new equipment to realize both operational efficiencies and security improvements. In addition, we are working on modernizing some of our legacy core and desktop software to ensure that we can stay within a vendor supported environment.

The increase in IT threats in the education space is also driving us to increase our focus around security. The higher ed community in Canada is seeing a big increase in successful attacks, with cases like the University of Calgary being hit with ransomware or the recent data breach and extortion demands at University of the Fraser Valley, and we don’t want to be counted on that list. University campuses are unique environments and therefore higher risk.

How is the academic situation unique?

Many would consider one of the functions of a university is to disseminate information. This leads to a philosophy that says systems should be open and accessible, which we have to balance with the very real need to protect important research and personal information.

This open access philosophy also applies to accessing outside resources. We only firewall outbound internet access as much as necessary to cover network level threats. We don’t use content filters, even in public computer labs.

Our users have widely different needs and technical capabilities, so we can’t really dictate how technology is used, like you might be able to do in a private corporation. We can say “you shouldn’t do that”, but it’s very difficult to say “you can’t do that” and make it stick.

How do you address these issues?

It all starts with policy development and user education. However, a policy only gets you so far.  So what we try to do is determine how our users want to do things and then give them easy and familiar ways to do them securely. In other words, what we try to do is make security as simple and transparent as possible and to provide users with tools that let them do what they want, how they want to do it, while complying with those policies.

Another way our team can help to mitigate risk is in the network architecture and how we deploy multiple security perimeters. For instance, we treat staff networks different than the student lab networks. By making the trusted zone as small as possible, we can focus our protection efforts there.

The Wi-Fi network is something we just keep completely segregated. Since we simply don’t have the resources to protect every wireless device on campus, we drop that traffic off on the outside of the firewall and treat it just like any other traffic from the internet.

Why did you implement the CIRA DNS Firewall?

We looked at an external firewall service as another form of intrusion protection system because it blocks outbound traffic from malware that gets in the system and it intercepts links to problem sites to keep problems out - and it works. It also meets our need to implement security that is seamless to the end user. It is very effective for us.  For example, like all universities, Trent is hammered with phishing attacks on a regular basis.  We are thrilled to bits at how quickly we can block these phishing pages using Firewall. If something does get through our existing layers of protection, we can quickly add it to the block list in Firewall. It has cut our impacted user rate by 80-90%. In addition to happy end users, that is a lot of time saved for our support team.