Security inside HeaNet router?

[G P Ashe]

Wondering what people are doing in general when it comes to perimeter security. 

Do you have hardware security appliance(s) sitting between HeaNet router and school LAN?

Apart from content filtering what other if any screening is performed remotely and therefore what level of security do schools connected to HeaNet have out of the box?

Do schools need to monitor web traffic and retain logs for a period? I understand that HeaNet will only release logs at the request of Garda. 

Interested in others views...

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
G P Ashe

@gpashe

+353 87 234 6850
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Eoghan Byrne]

Hey Greg

I know for our school we were fortunate enough to have a Sonicwall firewall for a period of time.

We would do weekly checks of it’s logs to find multiple DNS attacks, IP floods, Port Scanning - it essentially looked as if there was little to no security being provided by the HEAnet service. (This was our experience approx 2 Years ago and they may have made some major adjustments or none at all but this isn’t an attack on HEAnet!)

I personally don’t agree the Juniper router providing every client with an external IP address with essentially no security (+ with the recent ease of access to one click DDoS systems ... an external IP for a teacher machine a student might not like, might not end so well)

So we decided to purchase just a cheapo enterprise router, so it can handle to traffic, to essentially act like normal home/enterprise network, with one external IP address for the building and have our DHCP server allocate internal IP address behind what we called the ‘Internal Router’. The router we have doesn’t have the functionality of a Sonicwall Firewall but it means there is only one point of failure for the whole building.

Pros;

• One external IP address
• View some minimal logs
• Basic content filtering for certain IP ranges
• Can easily be switched back to Juniper Router for maintenance, etc

Cons;

• HEAnet split level filtering is more difficult to achieve
• One extra troubleshooting step if internet drops

We’ve hand our internal router in place for approx 2 years now and we’ve never had a single issue, whereas previous to our internal router there would be sporadic drops on certain machines and the likes.

We also did a major network overhaul with the ICT funding, here we had to keep the secretarial machines operating whilst the rest of the network was shutdown - this was easily done by changing just those required machines over to the Juniper Router, getting the machines to pull a new IP and we were done. We could then shutdown the rest of the network, carry out the maintenance and test that everything was functioning correctly before bringing the secretarial machines back onto the local network.

Other than just essentially having a double NAT setup, we don’t have internal content filtering so as far as I can remember we get Level 5 direct from HEAnet and do minimal content filtering on certain domains.

Also for the logs I’m not too sure what will come about from the new GDPR but with the internal router we have, we do have the option of periodic emails of the logs.

Eoghan

--
--
You received this message because you are subscribed to the Google
Groups "CESI-list" group.
To post to this group, send email to cesi...@googlegroups.com
To unsubscribe from this group, send email to cesi-list+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cesi-list?hl=en-GB where all messages are archived and are publically available to non members of the list. Messages may also show up in search engines etc.
Visit the web site www.cesi.ie
Attempts to use the list for commercial purposes may result removal from the list.
---
You received this message because you are subscribed to the Google Groups "CESI-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cesi-list+...@googlegroups.com.
To post to this group, send email to cesi...@googlegroups.com.
Visit this group at https://groups.google.com/group/cesi-list.
For more options, visit https://groups.google.com/d/optout.

Email Disclaimer

"This e-mail and any files transmitted with it are confidential and are intended solely for use by the addressee. Any unauthorised dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender and delete the message. Any views or opinions presented in this e-mail may solely be the views of the author and cannot be relied upon as being those of Blakestown Community School. E-mail communications such as this cannot be guaranteed to be virus-free, timely, secure or error-free and Blakestown Community School does not accept liability for any such matters or their consequences. Please consider the environment before printing this e-mail."

Séanadh Ríomhphoist

"Tá an ríomhphost seo agus aon chomhad a sheoltar leis faoi rún agus is lena úsáid ag an seolaí agus sin amháin é. Tá cosc iomlán ar scaipeadh, dháileadh nó chóipeáil neamhúdaraithe ar an teachtaireacht seo agus ar aon cheangaltán atá ag dul leis. Má tá an ríomhphost seo faighte agat trí dhearmad cuir sin in iúl le do thoil don seoltóir agus scrios an teachtaireacht. D’fhéadfadh sé gurb iad tuairimí an údair agus sin amháin atá in aon tuairimí no dearcthaí atá curtha i láthair sa ríomhphost seo agus níor chóir glacadh leo mar thuairimí nó dhearcthaí Pobalscoil Eanna. Ní ghlactar leis go bhfuil cumarsáid ríomhphoist den sórt seo saor ó víreas, in am, slán, nó saor ó earráid agus ní ghlacann Pobalscoil Eanna le dliteanas in aon chás den sórt sin ná as aon iarmhairt a d’eascródh astu. Cuimhnigh ar an timpeallacht le do thoil sula gcuireann tú an ríomhphost seo i gcló."

[Donal O]

My personal response (without knowing your budget, footrprint, and risk) is 100% should have your own firewall for additional protection. 

You should block all traffic initiated from external(untrusted) HEAnet WAN to internal(trusted/semi-trusted) LAN and DMZs. 

HEAnet provides *some* traditional port level protections on their router (more info below in the explicit answers section).

You then allow internal(trusted/semi-trusted) to external(untrusted) or some variation thereof. There are some caveats such as, if you are running servers locally or have remote support, you need to allow for those. Essentially one tenet of security is "defense-in-depth" and a layered approach is key, as devices, *especially* those without their own host firewall, have a greater "attack-surface" and are more at risk. The question is whether HEAnet basic blocking is "good enough" for your footprint of services and devices, and without standardisation across the country, unfortunately the answer is, it depends. It also depends upon your resources, budget, footprint, and (informed) risk tolerance.

As you can see from my "Defensible Schools Cheatsheet v5" https://proveit.podomere.com/dl/defensible_schools_cheatsheet_v5.pdf , I have a FW+router *below* the HEAnet router and your flows based upon risk zones can be modeled on this "Simple Security Model" https://proveit.podomere.com/dl/defensible_schools_simple_security_v5.pdf

There are multiple reasons not to have *any* device directly on the Internet with a public IP. There is a concept of "survival time" for unpatched and new devices directly connected to the Internet with no firewalling (be it host/network) and with laptops/mobile devices often it's about them being walked back in from somewhere else infected and attacking others laterally as another concern (or being controlled remotely). But it comes back to the idea of hosts not being secure in of themselves, assume everything will be exploited/fail at some point, and as such, having network level policy enforcement and auditing is crucial. Never rely on hosts only, never rely on network only. 

NAT(Network Address Translation) is a mechanism that translates IP addresses from one network to another and typically one uses it to allow for many private IP addresses to talk *via* a Public IP address or Public Pool to the rest of the Internet. NAT is *not* a security mechanism per se but helps by defining what flows get translated and which don't. There are different flavours of NAT for different scenarios (and sometimes called slightly different things per vendor implementation). Also, if the number of devices grows at any point, you can easily hide them behind NAT and grow your pools without having to get HEAnet to re-address or incur outages. Additionally for guest networks etc. you don't limit yourself with the available number of Public IP addresses HEAnet has given you.

A firewall is a policy enforcement device and can *also* be an audit device and even look inside traffic to protect from malware or block flows based upon multiple types of content (just as HEAnet does with their Palo Alto filtering in via their centralised HEAnet services). These days firewalls of a certain calibre are more likely to be multifunctional and called Unified Threat Management devices. With some DPI(Deep Packet Inspection) you can not only increase your situational awareness but block certain attacks.... but my primary usage is for capacity management and applying subsequent quality of service for different applications by promoting or demoting them to preserve bandwidth or change user behaviour. If you consider the Internet to be "untrusted" that's a good start and then you can build policy for who can go where via concepts of "trusted" and "semi-trusted".

One of the reasons to use certain endpoint devices in schools and move servers to the cloud, is to reduce the footprint and attack surface of services in the school themselves. There is a growing movement around an architecture called "Zero Trust" which is more data-centric but takes a huge amount of resources in terms of architecture, expertise, and management overheads. Legacy schools are not ready for a "Zero Trust" architecture yet IMHO, albeit by default, many have aspects of one already (in a bad way). There are arguments about this approach still in industry which go all the way back to the Jericho Forum - however I personally would see a vision of "zero trust thin schools" in the future (once this country gets serious about funding faster and more robust connectivity). 

Effectively I expected more from the powers that be around physical *and* logical architecture for small, medium, and large schools but wasn't too surprised nothing like this existed. Some of the best and simplest writing on security principles comes from an Australian ex-colleague: http://www.securearc.com/wiki/index.php/Security_Principles and http://www.securearc.com/wiki/index.php/Logical_Security_Zone_Pattern which is applicable to enterprises but can be 'cherry picked' for schools scenarios.

Explicit answers to your questions:

===========================

a) Do you have hardware security appliance(s) sitting between HEAnet router and school LAN?

Yes you should unless you financially can't afford to (either in terms of CAPEX and/or OPEX).

b) Apart from content filtering what other if any screening is performed remotely and therefore what level of security do schools connected to HeaNet have out of the box?

The schools routers from HEAnet seem to block most Microsoft RPC UDP/TCP ports which are major vectors for *Microsoft* malware(worms/viruses). They also only allow DNS to/from the HEAnet DNS servers and block all other UDP. They allow TCP connections outbound on any port and only *established* TCP connections back in. What I am not sure about yet is what else HEAnet inspect via their Palo Alto's e.g. torrents... or explicit malware via IDS/IDP.

Inbound web content filtering can be applied per subnet/IP range whereupon it's beneficial to have teachers and students NAT'd to/from different IPs/pools hence the split level capability by IP/subnet being easier in some ways. 

 - b1) http://www.pdsttechnologyineducation.ie/en/Technology/Schools-Broadband/Content-Filtering/ and http://support.scoilnet.ie/index.php/Filtering#Split-Level_Filtering

 - b2) badly phrased http://www.pdsttechnologyineducation.ie/en/Technology/Schools-Broadband/Security/ but effectively states they only look at return http(https) traffic and inbound SMTP mail delivery inbound for malware and blocking via PANs(Palo Alto Networks) FWs. This is for schools running their own local mail servers.

Note: I am asking around my network contacts in/from/to confirm HEAnet's exact technical measures and how...  :)

c) Do schools need to monitor web traffic and retain logs for a period?

I can't answer this yet but it's best current practice to keep a range of logs for as long as practicable. Usually 7-30days hot and 30+ days cold. It is not feasible to keep all flow records and 'blocks' or 'permits' on a firewall indefinitely (also for performance reasons) but you can keep IP to MAC mappings (DHCP records) and certain "events" that alert from chosen policies.

Please retain healthy doubt for all I have said above and validate for yourself with broadbands...@pdst.ie *specifically* asking them to check with n...@schools.edu.ie 

Humble regards,

Donal O Duibhir

https://www.linkedin.com/in/podomere/

[Imogen Bertin]

Wow Donal - I dunno why you are being humble in your regards - that is fantastic quality, clear information! I love CESI!

Imogen

On Sun, Feb 11, 2018 at 5:22 PM, Donal O <irld...@gmail.com> wrote:

My personal response (without knowing your budget, footrprint, and risk) is 100% should have your own firewall for additional protection. 

You should block all traffic initiated from external(untrusted) HEAnet WAN to internal(trusted/semi-trusted) LAN and DMZs. 

HEAnet provides *some* traditional port level protections on their router (more info below in the explicit answers section).

You then allow internal(trusted/semi-trusted) to external(untrusted) or some variation thereof. There are some caveats such as, if you are running servers locally or have remote support, you need to allow for those. Essentially one tenet of security is "defense-in-depth" and a layered approach is key, as devices, *especially* those without their own host firewall, have a greater "attack-surface" and are more at risk. The question is whether HEAnet basic blocking is "good enough" for your footprint of services and devices, and without standardisation across the country, unfortunately the answer is, it depends. It also depends upon your resources, budget, footprint, and (informed) risk tolerance.

As you can see from my "Defensible Schools Cheatsheet v5" https://proveit.podomere.com/dl/defensible_schools_cheatsheet_v5.pdf , I have a FW+router *below* the HEAnet router and your flows based upon risk zones can be modeled on this "Simple Security Model" https://proveit.podomere.com/dl/defensible_schools_simple_security_v5.pdf

There are multiple reasons not to have *any* device directly on the Internet with a public IP. There is a concept of "survival time" for unpatched and new devices directly connected to the Internet with no firewalling (be it host/network) and with laptops/mobile devices often it's about them being walked back in from somewhere else infected and attacking others laterally as another concern (or being controlled remotely). But it comes back to the idea of hosts not being secure in of themselves, assume everything will be exploited/fail at some point, and as such, having network level policy enforcement and auditing is crucial. Never rely on hosts only, never rely on network only. 

NAT(Network Address Translation) is a mechanism that translates IP addresses from one network to another and typically one uses it to allow for many private IP addresses to talk *via* a Public IP address or Public Pool to the rest of the Internet. NAT is *not* a security mechanism per se but helps by defining what flows get translated and which don't. There are different flavours of NAT for different scenarios (and sometimes called slightly different things per vendor implementation). Also, if the number of devices grows at any point, you can easily hide them behind NAT and grow your pools without having to get HEAnet to re-address or incur outages. Additionally for guest networks etc. you don't limit yourself with the available number of Public IP addresses HEAnet has given you.

A firewall is a policy enforcement device and can *also* be an audit device and even look inside traffic to protect from malware or block flows based upon multiple types of content (just as HEAnet does with their Palo Alto filtering in via their centralised HEAnet services). These days firewalls of a certain calibre are more likely to be multifunctional and called Unified Threat Management devices. With some DPI(Deep Packet Inspection) you can not only increase your situational awareness but block certain attacks.... but my primary usage is for capacity management and applying subsequent quality of service for different applications by promoting or demoting them to preserve bandwidth or change user behaviour. If you consider the Internet to be "untrusted" that's a good start and then you can build policy for who can go where via concepts of "trusted" and "semi-trusted".

One of the reasons to use certain endpoint devices in schools and move servers to the cloud, is to reduce the footprint and attack surface of services in the school themselves. There is a growing movement around an architecture called "Zero Trust" which is more data-centric but takes a huge amount of resources in terms of architecture, expertise, and management overheads. Legacy schools are not ready for a "Zero Trust" architecture yet IMHO, albeit by default, many have aspects of one already (in a bad way). There are arguments about this approach still in industry which go all the way back to the Jericho Forum - however I personally would see a vision of "zero trust thin schools" in the future (once this country gets serious about funding faster and more robust connectivity). 

Effectively I expected more from the powers that be around physical *and* logical architecture for small, medium, and large schools but wasn't too surprised nothing like this existed. Some of the best and simplest writing on security principles comes from an Australian ex-colleague: http://www.securearc.com/wiki/index.php/Security_Principles and http://www.securearc.com/wiki/index.php/Logical_Security_Zone_Pattern which is applicable to enterprises but can be 'cherry picked' for schools scenarios.

Explicit answers to your questions:

===========================

a) Do you have hardware security appliance(s) sitting between HEAnet router and school LAN?

Yes you should unless you financially can't afford to (either in terms of CAPEX and/or OPEX).

b) Apart from content filtering what other if any screening is performed remotely and therefore what level of security do schools connected to HeaNet have out of the box?

The schools routers from HEAnet seem to block most Microsoft RPC UDP/TCP ports which are major vectors for *Microsoft* malware(worms/viruses). They also only allow DNS to/from the HEAnet DNS servers and block all other UDP. They allow TCP connections outbound on any port and only *established* TCP connections back in. What I am not sure about yet is what else HEAnet inspect via their Palo Alto's e.g. torrents... or explicit malware via IDS/IDP.

Inbound web content filtering can be applied per subnet/IP range whereupon it's beneficial to have teachers and students NAT'd to/from different IPs/pools hence the split level capability by IP/subnet being easier in some ways. 

 - b1) http://www.pdsttechnologyineducation.ie/en/Technology/Schools-Broadband/Content-Filtering/ and http://support.scoilnet.ie/index.php/Filtering#Split-Level_Filtering

 - b2) badly phrased http://www.pdsttechnologyineducation.ie/en/Technology/Schools-Broadband/Security/ but effectively states they only look at return http(https) traffic and inbound SMTP mail delivery inbound for malware and blocking via PANs(Palo Alto Networks) FWs. This is for schools running their own local mail servers.

Note: I am asking around my network contacts in/from/to confirm HEAnet's exact technical measures and how...  :)

c) Do schools need to monitor web traffic and retain logs for a period?

I can't answer this yet but it's best current practice to keep a range of logs for as long as practicable. Usually 7-30days hot and 30+ days cold. It is not feasible to keep all flow records and 'blocks' or 'permits' on a firewall indefinitely (also for performance reasons) but you can keep IP to MAC mappings (DHCP records) and certain "events" that alert from chosen policies.

Please retain healthy doubt for all I have said above and validate for yourself with broadbandservicedesk@pdst.ie *specifically* asking them to check with n...@schools.edu.ie 

Humble regards,

Donal O Duibhir

https://www.linkedin.com/in/podomere/

On Saturday, 10 February 2018 11:09:57 UTC, gpa wrote:

Wondering what people are doing in general when it comes to perimeter security. 

Do you have hardware security appliance(s) sitting between HeaNet router and school LAN?

Apart from content filtering what other if any screening is performed remotely and therefore what level of security do schools connected to HeaNet have out of the box?

Do schools need to monitor web traffic and retain logs for a period? I understand that HeaNet will only release logs at the request of Garda. 

Interested in others views...

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
G P Ashe

@gpashe

+353 87 234 6850
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--

--
You received this message because you are subscribed to the Google
Groups "CESI-list" group.
To post to this group, send email to cesi...@googlegroups.com

To unsubscribe from this group, send email to cesi-list+unsubscribe@googlegroups.com

For more options, visit this group at http://groups.google.com/group/cesi-list?hl=en-GB where all messages are archived and are publically available to non members of the list. Messages may also show up in search engines etc.
Visit the web site www.cesi.ie
Attempts to use the list for commercial purposes may result removal from the list.
---
You received this message because you are subscribed to the Google Groups "CESI-list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cesi-list+unsubscribe@googlegroups.com.

To post to this group, send email to cesi...@googlegroups.com.
Visit this group at https://groups.google.com/group/cesi-list.
For more options, visit https://groups.google.com/d/optout.

--

Reagrove, Minane Bridge, Co. Cork, Ireland P17 KH32
Tel: +353 87 2655261 Landline: 021 4887300 Email: imo...@ctc.ie 

https://www.techability.ie 

[Greg Ashe]

Many thanks Donal and Eogfhan - excellent responses.

However I wonder how many schools are implementing some/all of these precautions?

Gregory Ashe

IT Manager

Main: +353 61 621010

Direct: +353 61 386443

Mobile: +353 87 2346850

Email: g...@glenstal.com

www.glenstal.com

---

NB Disclaimer Important: ​

Information in this email (including attachments) is confidential. It is intended for receipt and consideration only by the intended recipient. If you are not an addressee or intended recipient, any use, dissemination, distribution, disclosure, publication or copying of information contained in this email is strictly prohibited. Opinions expressed in this email may be personal to the author and are not necessarily the opinions of Glenstal Abbey or Glenstal Abbey School. If this email has been received by you in error we would be grateful if you could immediately notify the sender, and thereafter delete this e-mail from your system.  

You are requested to carry out your own virus check before opening any attachment. The author, as well as Glenstal Abbey and Glenstal Abbey School, accept no liability for any loss or damage which may be caused by viruses, malware or malicious software.

​

Please consider the environment before printing this email.​

---

[Donal O]

I should note that that my reference about Microsoft services ports and TCP established + UDP ports + directionality only applies to Cisco HEAnet routers. I need to research the Juniper Networks router situation which speaks to Eoghan's response...

On Sunday, 11 February 2018 17:49:53 UTC, Donal O wrote:

My personal response (without knowing your budget, footrprint, and risk) is 100% should have your own firewall for additional protection. 

You should block all traffic initiated from external(untrusted) HEAnet WAN to internal(trusted/semi-trusted) LAN and DMZs. 

HEAnet provides *some* traditional port level protections on their router (more info below in the explicit answers section).

You then allow internal(trusted/semi-trusted) to external(untrusted) or some variation thereof. There are some caveats such as, if you are running servers locally or have remote support, you need to allow for those. Essentially one tenet of security is "defense-in-depth" and a layered approach is key, as devices, *especially* those without their own host firewall, have a greater "attack-surface" and are more at risk. The question is whether HEAnet basic blocking is "good enough" for your footprint of services and devices, and without standardisation across the country, unfortunately the answer is, it depends. It also depends upon your resources, budget, footprint, and (informed) risk tolerance.

As you can see from my "Defensible Schools Cheatsheet v5" https://proveit.podomere.com/dl/defensible_schools_cheatsheet_v5.pdf , I have a FW+router *below* the HEAnet router and your flows based upon risk zones can be modeled on this "Simple Security Model" https://proveit.podomere.com/dl/defensible_schools_simple_security_v5.pdf

There are multiple reasons not to have *any* device directly on the Internet with a public IP. There is a concept of "survival time" for unpatched and new devices directly connected to the Internet with no firewalling (be it host/network) and with laptops/mobile devices often it's about them being walked back in from somewhere else infected and attacking others laterally as another concern (or being controlled remotely). But it comes back to the idea of hosts not being secure in of themselves, assume everything will be exploited/fail at some point, and as such, having network level policy enforcement and auditing is crucial. Never rely on hosts only, never rely on network only. 

NAT(Network Address Translation) is a mechanism that translates IP addresses from one network to another and typically one uses it to allow for many private IP addresses to talk *via* a Public IP address or Public Pool to the rest of the Internet. NAT is *not* a security mechanism per se but helps by defining what flows get translated and which don't. There are different flavours of NAT for different scenarios (and sometimes called slightly different things per vendor implementation). Also, if the number of devices grows at any point, you can easily hide them behind NAT and grow your pools without having to get HEAnet to re-address or incur outages. Additionally for guest networks etc. you don't limit yourself with the available number of Public IP addresses HEAnet has given you.

A firewall is a policy enforcement device and can *also* be an audit device and even look inside traffic to protect from malware or block flows based upon multiple types of content (just as HEAnet does with their Palo Alto filtering in via their centralised HEAnet services). These days firewalls of a certain calibre are more likely to be multifunctional and called Unified Threat Management devices. With some DPI(Deep Packet Inspection) you can not only increase your situational awareness but block certain attacks.... but my primary usage is for capacity management and applying subsequent quality of service for different applications by promoting or demoting them to preserve bandwidth or change user behaviour. If you consider the Internet to be "untrusted" that's a good start and then you can build policy for who can go where via concepts of "trusted" and "semi-trusted".

One of the reasons to use certain endpoint devices in schools and move servers to the cloud, is to reduce the footprint and attack surface of services in the school themselves. There is a growing movement around an architecture called "Zero Trust" which is more data-centric but takes a huge amount of resources in terms of architecture, expertise, and management overheads. Legacy schools are not ready for a "Zero Trust" architecture yet IMHO, albeit by default, many have aspects of one already (in a bad way). There are arguments about this approach still in industry which go all the way back to the Jericho Forum - however I personally would see a vision of "zero trust thin schools" in the future (once this country gets serious about funding faster and more robust connectivity). 

Effectively I expected more from the powers that be around physical *and* logical architecture for small, medium, and large schools but wasn't too surprised nothing like this existed. Some of the best and simplest writing on security principles comes from an Australian ex-colleague: http://www.securearc.com/wiki/index.php/Security_Principles and http://www.securearc.com/wiki/index.php/Logical_Security_Zone_Pattern which is applicable to enterprises but can be 'cherry picked' for schools scenarios.

Explicit answers to your questions:

===========================

a) Do you have hardware security appliance(s) sitting between HEAnet router and school LAN?

Yes you should unless you financially can't afford to (either in terms of CAPEX and/or OPEX).

b) Apart from content filtering what other if any screening is performed remotely and therefore what level of security do schools connected to HeaNet have out of the box?

The schools routers from HEAnet seem to block most Microsoft RPC UDP/TCP ports which are major vectors for *Microsoft* malware(worms/viruses). They also only allow DNS to/from the HEAnet DNS servers and block all other UDP. They allow TCP connections outbound on any port and only *established* TCP connections back in. What I am not sure about yet is what else HEAnet inspect via their Palo Alto's e.g. torrents... or explicit malware via IDS/IDP.

Inbound web content filtering can be applied per subnet/IP range whereupon it's beneficial to have teachers and students NAT'd to/from different IPs/pools hence the split level capability by IP/subnet being easier in some ways. 

 - b1) http://www.pdsttechnologyineducation.ie/en/Technology/Schools-Broadband/Content-Filtering/ and http://support.scoilnet.ie/index.php/Filtering#Split-Level_Filtering

 - b2) badly phrased http://www.pdsttechnologyineducation.ie/en/Technology/Schools-Broadband/Security/ but effectively states they only look at return http(https) traffic and inbound SMTP mail delivery inbound for malware and blocking via PANs(Palo Alto Networks) FWs. This is for schools running their own local mail servers.

Note: I am asking around my network contacts in/from/to confirm HEAnet's exact technical measures and how...  :)

c) Do schools need to monitor web traffic and retain logs for a period?

I can't answer this yet but it's best current practice to keep a range of logs for as long as practicable. Usually 7-30days hot and 30+ days cold. It is not feasible to keep all flow records and 'blocks' or 'permits' on a firewall indefinitely (also for performance reasons) but you can keep IP to MAC mappings (DHCP records) and certain "events" that alert from chosen policies.

Please retain healthy doubt for all I have said above and validate for yourself with broadbandservicedesk@pdst.ie *specifically* asking them to check with n...@schools.edu.ie