Defense in Depth and Network Defenses
Have a network-based firewall or access-list
Primary network managers should make sure that their subnets have some sort of network based access-control, whether it's with a firewall, RACL, etc, and that the rules on the firewall/RACL are up to date. A properly configured firewall can significantly reduce a network's exposure to outside attacks.
Secure your subnet on the campus perimeter firewall
Network managers can also consider having their subnets protected on the perimeter firewall, to block much of the constant scanning coming into campus from the Internet at large.
Require your users to VPN
Having your users VPN when working remotely not only encrypts their data as it traverses the network between their remote computer and the campus network, it also allows you to tighten down your firewall rules significantly. For example, instead of allowing SSH access from anywhere in the world, the firewall rules can allow just the campus VPN range while still allowing vacationing members of your department to connect. If requiring VPN'ing isn't an option in your environment, consider setting up a bastion host as a jump-off point before allowing connections to more sensitive systems.
See what other services SecOps can offer
For more information on network-based defenses which SecOps can offer departments, see:
Have and enforce departmental security policies in addition to the University policies
The University security policies (pdf) apply to the entire campus, and needs to be very broad due to the variety of functions in different departments across campus. Depending on the function of your department, it may be highly advisable to have your own departmental security policies which can be much tighter and tailored to your business workflow. For instance, a business unit may wish to have a departmental security policy which can be much stricter than the University's overall security policies which applies not just to business units, but also to academic units and individual students.
If all else fails, have a Disaster Recovery Plan
Think about a worst case scenario, and have a Disaster Recovery Plan. Just as an example, consider how you'd go about business if 'server X' went down for a day, or if all data on 'server Y' was irrevocably lost. Make sure that any plan and mechanisms (such as backups) which you have in place is tested on a regular basis, and especially after major changes.
Detecting a Compromise
If you detect a suspected compromise, disconnect your system from the network (both wired and wireless!), but do not reboot/turn off your computer unless instructed to do so. Note that under no conditions should you launch a 'counterhack' against the apparently offending host. Not only is 'counterhacking' illegal and opens you up to legal liabilities, it also will probably just be targeting another victim machine, since most attackers will use multiple hops between their own system and the target.
Certain service anomalies warrant immediate attention, such as any remote administration software (Dameware, VNC, etc) which shouldn't be there, if an IRC client (mIRC, etc) is installed/running when it shouldn't be, or if new admin accounts are appearing. Please report the incident if you find signs of compromise.
Lenny Zeltser has an excellent Security Incident Survey Cheat Sheet for Server Administrators which can serve as a checklist for items to look for in a generic potential incident situation:
SANS has a good pair of cheatsheets for detecting general signs of compromise:
There are a number of security applications which can help with detecting rootkits, such as: