Logging and Monitoring

What are the benefits and issues with correlating identities across the enterprise? What are the issues relating to cross walking and characteristics of identifiers? What strategies are there for getting the most out of logging? It’s important to know if an identifier has been reassigned, for instance, when using it for access to restricted spaces. Are there new institutional processes we should consider, such as logging in to register your IP address and binding an IP with a user? This session will explore these questions and offer a set of common requirements.

Designing and implementing a network, server, and application architecture for 24 x 7 Web application delivery is a must in today's demanding business environment. This presentation will cover the planning, complexities to address, and necessary steps to achieve reliable delivery of campus-wide financial, human resources, and student applications.

The author suggests that schools may be purposely not retaining IP logging data on students to protect them from copyright infringement lawsuits.

Intrusion detection was a high priority for the Notre Dame Information Security Department when it was created about a year and a half ago. The university's Responsible Use Policy contains a clause that codifies the university's right to "inspect and examine any Notre Dame owned or operated communications system, computing resource, and/or files or information contained therein at any time," enabling us to implement an intrusion detection system (IDS) with no resistance.

We evaluated the top commercial and open source network intrusion detection system (NIDS) products, including Snort. Ultimately, we found that the best fit was multiple Snort sensors managed using SnortCenter, with MySQL for data storage and ACID for display and reporting.

Overview of the University Network The University of Chicago's network has approximately 15,000 network devices on it, spanning across about a thousand switches. The network infrastructure is a 100 MB per second switched infrastructure with a gigabit backbone. For off campus connectivity, we currently have 155 MB/sec Internet2 connectivity, and two 40 MB/sec commodity links. We have a handful of T1 and T3 connections which connect into our campus backbone for affiliated organizations or sites away from the main campus network. Evolution of Network Forensics at the University We have been running various network forensic tools since around 1995. We started with TAMU NetLogger logging traffic on the subnet on which we had our main e-mail, Web, and other important servers. NetLogger relied on a non-switched network for logging. As the University's network swapped over to a switched network we stopped using NetLogger. Around 1998, as the university started the Network Security Center, we started searching for a way to have similar network audit logs, except to monitor traffic across the university's gateway instead of or in addition to monitoring the main servers.

Windows NT-derived systems are able to record many kinds of information on user authentication. The logs generated are very detailed but difficult to analyze with the tools provided, which cannot summarize or report on the information that the log contains (other than a primitive filtering function). I wrote a Perl script, called logger.pl, that can read the security log from one or more Windows machines and summarize the information it contains to produce a report of what it finds, detailing the types of authentications that occurred, which usernames and client machines were involved, and the result. The output can be e-mailed to a given user (with PGP encryption available if PGP is installed on the host system), written to a file, or simply displayed on the screen. This script is very useful for many purposes, ranging from finding what systems a particular user has "touched" to summarizing authentication activity over a large number of systems. A recently added function generates a CSV file when multiple systems are scanned that can be imported and analyzed to produce, for example, a 3D graph of authentication activity on a user-to-machine basis.

The Maricopa Community Colleges consist of 10 colleges, two skill centers, and many college satellite centers, including classes being held at the Arizona state prison. More than 200,000 students are enrolled, supported by approximately 11,000 employees. This translates to roughly 25,000 network hosts. Maricopa has a decentralized administration, with each college having a president and a full complement of deans. The district office administration handles core, centralized, administrative operations such as human resources and financials. The colleges have diverse missions, from purely occupational to largely academic colleges. One college is solely distance learning.