Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

What Information Is ITS Logging and Monitoring, To Keep the Campus Safe?

2017 was a watershed year for cybersecurity.  In the wake of highly publicized breaches like the Equifax hack, new vulnerabilities like Spectre and Meltdown, and widespread ransomware attacks, many Carleton users have asked what all ITS is doing--in particular how we stay aware of what is happening on our network and keep users as safe as we reasonably can.

The purpose of this page is to summarize the basics of what we are doing.

Please note that ITS does not track individual users, per se, or what they do.  Rather, we log and track normal activity in aggregate, and respond to unusual activity, indications of compromise, and malware.  We look in detail at individual activity only to the extent needed to respond appropriately, for example, notifying the user and (rarely) locking their account if that account appears to be compromised, to try to limit damage not only to the campus, but to the user's own information and resources.

 

Asset Tracking

Centrally, ITS also tracks what users and departments are assigned what hardware, and we also track what hardware needs replacement and when.  This is done through asset management software, and is keyed to the CCID of the hardware, i.e., the barcode sticky affixed to most deployed hardware.  Everyone in ITS can see this data.  We need it to know where to go if a physical asset needs attention or replacement.


Patching

Windows machines on campus take their operating system updates from a local patch server.  This server tells us what machines have updated when, and which updates were applied.  We need this information in order to ensure that everyone's computer is up to date and not vulnerable to any obvious intrusions or attacks.  It turns out that, out of all the various defenses users, and ITS, can deploy, simply keeping devices up to date is the very best and most effective.

Software Deployment, Packaging

The software inventory, operating system, and general configuration parameters are recorded in software we purchase from Dell Computing, called KBox.  This software helps us package up other software for easy installation in labs and on user devices like desktops and laptops.  Often a particular piece of software will require a special license key, or will need to be pointed at a particular device on campus.  The KBox can automate these configuration steps.  It can also tell us if, for example, a piece of software needs updating and can take the needed action.  This is particularly useful when a serious security issue has been discovered.  ITS staff can see this data.  We need it in order to understand and diagnose software issues that users call about, and to know where to put what software.  We also need it in order to find machines that are not updating their software correctly and are therefore exposing users to hostile activity and malware, or opening them and Carleton to licensing violations.

Keyserver Logging, License Management

Data is also logged regarding what software is executed, where, and when, via keyserver software, Sassafras.  We do this, when needed, for audit and compliance purposes.  General information at this level is visible to a handful of people including desktop computing and software asset management specialists, the IT security officer, and the data warehouse administrator.

Network-Level Logging

In general, nearly all devices through which traffic passes on Carleton’s network log that traffic.  These logs typically include the source and destination IP address, MAC address, and various other relevant details.  Additional detail gets logged for WiFi via PacketFence.  This data, collectively, allows us to locate and fix problems and bottlenecks, and it helps us diagnose problems when we (or our users) discover them.  We normally don’t look at this data in detail unless there is a problem.  The number of people who can do this is very limited (a few core systems staff and the IT security officer).

The Firewall

Additionally, ITS protects the campus with a central firewall, which inspects traffic as it flows through and looks for infiltration attempts, brute-force scans of our network, and other hostile activity, and logs and/or outright blocks the activity, depending on its severity.  ITS does not examine logs produced by the firewall, except when performing forensics or examining alert notices.  The number of people who can do this is very limited (a few core systems staff and the IT security officer).

Machine-Level Logging

Individual machines (Linux servers, Windows servers, and Windows desktops) also log what they are doing, locally.  There are, for one thing, antivirus and local firewall logs.  There are also general system logs.  These latter logs are written not only to local disk, but also forwarded to a central syslog server, then on to a central repository (Splunk).  Every time a Windows machine executes a program, it is also recorded separately, along with the policy that applies to it (AppLocker).  ITS knows nothing about what the programs are really doing.  But we do use the basic information provided in logs to detect malware-related infestations, and also to perform forensics when and if hostile activity is discovered.

Log data forwarded to Splunk is particularly useful in detecting campus-wide events, and for looking back to see what happened, even if attackers have erased logs on the machine(s) they attacked to cover their tracks.  Forwarded log data also allow us to infer what “normal” behavior is and construct alerts when something abnormal is detected, like a login from a staff member in France, and a login from that same person a few minutes later in China.  The number of people who can perform this sort of analysis and set up alerts is very limited (a few core systems staff and the IT security officer), and once set up, the alerts only fire when an anomaly is detected.  When that happens, ITS's analysis process only brings in what detail is needed in order for us to take appropriate action, like verifying that the anomaly is in fact due to compromise, informing users as needed, and locking applicable accounts temporarily to prevent anything worse from happening.


Richard Goerwitz
January 2018

  • No labels