IT Architecture Team Report:
IT Processes

Overview

This reference document describes the security-related processes provided by OIT at Princeton and, as appropriate, links to additional related information. Processes include the following services:

• Basic authentication
• Enhanced authentication
• Password management
• Authorization
• Identity management
• Certificate management
• Encryption
• Digital signatures
• Firewalls

Basic Authentication

Authentication is the act of verifying that an individual loggging into a system or application is who he or she claims to be. Typical methods of authentication include the use of passwords, smart tokens (such as RSA SecurID), digital certificates and biometrics. Authentication systems that solely rely on passwords are referred to as basic authentication systems.

OIT maintains two centrally managed, password-based authentication services that can be used by systems and applications that require end user authentication: LDAP and Active Directory. Both are equally acceptable methods. When implementing a system or application, the choice of which of these two methods to use should be governed by ease of implementation.

Generally, applications implemented on Windows systems are more easily integrated with Active Directory. LDAP is the more likely choice for non-Windows systems and applications.

A Help Desk article describes the steps for using Princeton’s LDAP Directory for authentication with Web applications.

The use of other authentication methods, such as the maintenance of user IDs and passwords within application databases is strongly discouraged for the following reasons:

• The quality of custom password protection code is difficult to ascertain over tried-and-true methods.
• Application code would need to be regularly reviewed to ensure that back doors do not exist to expose passwords.
• The more objects that have access to password values, the greater the opportunity for those password to be compromised.

Enhanced Authentication

Smart Tokens

OIT supports a smart token service for situations that are sensitive enough to require an additional layer of authentication protection. This service requires that end users have in their possession an assigned RSA SecurID token in addition to knowing their password. The RSA SecurID token is a key fob (a plastic object that can be attached to a key ring) with a digital LCD display. The user proves that he or she has the key fob in his or her possession by typing into the system his or her PIN and the number that is currently displayed on the key fob which changes to a completely different value each minute.

Currently, enhanced authentication is used by system and application support personnel who need administrator-level access to their assigned systems.

To obtain an RSA SecurID, you must submit a form to the Information Security Officer.

Digital Certificates

Digital certificates also can be used for enhanced authentication in specific circumstances defined by each system or application. For example, not only can digital certificates be used to authenticate a user to an application configured to use digital certificates, but they could also be used to cross-authenticate systems, e.g., a client workstation and a server, an application server and a database server, etc.

Digital certificates must be issued by an approved Certificate Authority (see Certificate Management below).

Password Management

OIT provides end users with a password synchronization service, called P-Synch, for maintaining passwords on Active Directory and LDAP. This tool allows each user to synchronize the passwords across the two systems or to choose to give them each a different value. When a user enters a new password into P-Synch, the tool checks the strength of the password against University policy and will reject any pasword it determines is too easy to guess. To ensure that password strength is enforced consistently across our centrally managed authentication services, the local password changing facility for LDAP and for Windows accounts in the Princeton domain have been disabled, so that all password changes must be entered via P-Synch.

To change passwords using P-Synch, click here.

Authorization

Authorization is the act of determining the files and other objects to which an authenticated user has access, and the type of access (e.g., read only, read-write, no access, full control) the user has to each of those objects.

Currently, authorization is administered through native system mechanisms, i.e., access control lists (ACLs), UNIX owner-group-world permissions, database privileges, application controls, etc. Application developers are responsible for setting up authorization mechanisms for their specific applications.

When planning how access is to be authorized, it is recommended that access privileges be assigned to user groups rather than individual user IDs. Typically, these groups are organized by job function. The primary benefit of such an approach is that new users need only to be added to the group to obtain their access privileges without having to modify individual permissions on system and application objects. Additionally, users who leave their role only need to be removed from the group rather than having to search through all system and application objects for instances of his or her user ID.

There are presently no central mechanisms offered by OIT for authorizing access to files and objects that span across multiple platforms.

Identity Management

The University's LDAP directory is provisioned from the University’s models for faculty, staff and students. It is the most comprehensive local directory for associating a University user ID with publicly-available information associated with its owner.

Certificate Management

When systems or applications require the use of server- and/or client-side, it is the responsibility of the system or application owner to obtain the appropriate digital certificates from one of the Certificate Authorities approved by OIT. The following CAs are approved at this time:

• Thawte
• Verisign

OIT currently does not provide Certificate Authority services.

Encryption

Confidential information transported across internal, external and wireless networks must be encrypted using the Secure Sockets Layer (SSL) encryption method with a minimum of a 128-bit encryption key. TLS is also an acceptable encryption alternative. Other equivalent encryption systems will be considered on a case-by-case basis.

For end-to-end encryption, most e-mail clients now provide embedded encryption and digital signature services. However, public keys will need to be exchanged between senders and recipients until procedures to manage a campus-wide public key infrastructure are adopted.

Note - It is critical that private encryption keys be escrowed to ensure that encrypted documents can be recovered in cases where the private key is corrupted or otherwise inaccessible, or the key holder is no longer available.

Digital Signatures

In applications where non-repudiation is required, i.e., measures must be taken so that the sender of information can not deny sending the information or a recipient cannot deny receiving the information, digital signatures can be very valuable. There are two acceptable types of digital signatures:

Digital Signatures Using Public Key Encryption Technology

These signatures enforce non-repudiation using digital certificate technology. Basically, a known value is encrypted with the initiator's private key to which only he or she has access (the certificate is password protected). If the value can be decrypted with that person's public key, that is considered proof that the initiator "signed" the document.

Digitized Physical Signatures

A digitized physical signature is a value that is created by the initiator physically writing his or her signature onto an electronic tablet which produces a value that reflects the pen movement, pressure, speed, etc. of the person doing the signing.

Firewalls

OIT provides firewall consulting services for teams supporting systems and application that require additional network security.

When a firewall is deemed to be required for a three-tiered application (i.e., client workstation, Web or application server, and database server), the application servers are typically connected to a firewall zone known as the De-Militarized Zone or DMZ. The database servers would be placed in the more protected "Trusted" zone, since they are usually accessed only by the Web or application server. This is done to protect the database information against a compromise of the application server, since all transactions between the two devices would have to traverse the firewall.

For two-tiered applications (e.g., client workstation and application/database server), the application/database server can be placed in either the "DMZ" or the "Trusted" zone depending on the risk posed by the system to other devices in the zone. The general rule is, if risk posed is high, the device should be placed in a DMZ or an isolated zone. If low, it can be placed in the "Trusted" zone.