Related Policies, Procedures and Resources

Data Classification Rule
Data Protection Rule

While the responsibility to classify data rest with the data steward there are some predefined types of sensitive and restricted/PHI institutional data. Based upon state, federal, and contractual requirements that UAB is bound by, the following information assets have been predefined as Restricted or Sensitive data and must be protected:


Personally Identifiable Education Records-Covered under FERPA

Personally Identifiable Education Records are defined as any education records that contain one or more of the following personal identifiers:

       Student Number

       Grades, GPA, Credits Enrolled


       A list of personal characteristics or any other information that would make the student’s identity easily traceable


Personally Identifiable Financial Information (PIFI) - Covered under GLBA

For the purpose of meeting security breach notification requirements, PII is defined as a person’s first name or first initial and last name in combination with one or more of the following data elements:

       Social security number

       Government issued driver’s license number

       Date of Birth

       Financial account number in combination with a security code, access code or password that would permit access to the account

Payment Card Information- Covered under PCI DSS

Payment card information is defined as a credit card number (also referred to as a primary account number or PAN) in combination with one or more of the following data elements:

       Cardholder name

       Service code

       Expiration date

       CVC2, CVV2 or CID value

       PIN or PIN block

       Contents of a credit card’s magnetic stripe

Protected Health Information (PHI) - Covered under HIPAA

PHI is defined as any “individually identifiable” information that is stored by a Covered Entity, and related to one or more of the following:

       Past, present or future physical or mental health condition of an individual.

       Provision of health care to an individual.

       Past, present or future payment for the provision of health care to an individual.

PHI is considered “individually identifiable” if it contains one or more of the following identifiers:


       Address (all geographic subdivisions smaller than state including street address, city, county, precinct or zip code)

       All elements of dates (except year) related to an individual including birth date, admissions date, discharge date, date of death and exact age if over 89)

       Telephone/Fax numbers

       Electronic mail addresses

       Social security numbers

       Medical record numbers

       Health plan beneficiary numbers

       Account numbers

       Certificate/license numbers

       Vehicle identifiers and serial numbers, including license plate number

       Device identifiers and serial numbers

       Universal Resource Locators (URLs)

       Internet protocol (IP) addresses

       Biometric identifiers, including finger and voice prints

       Full face photographic images and any comparable images

       Any other unique identifying number or characteristic that could identify an individual

If the health information does not contain one of the above referenced identifiers and there is no reasonable basis to believe that the information can be used to identify an individual, it is not considered “individually identifiable” and; as a result, would not be considered PHI.

Note:  Any information classified differently per regulation or policy will be protected at the highest classification level.  For example, social security number as part of a student’s record.  The social security number is not classified as Sensitive Data under FERPA.  It is classified as Restricted Data as Personally Identifiable Information (PII) and under GLBA.
February 16, 2015

Transport Layer Security

UAB’s information systems rely on encryption to protect data from being intercepted.

Certain configurations have proven insecure. The following guidance provides configurations for acceptable protocols for all services that are protected by Transport Layer Security (TLS) as well as sensitive information protected by these services.

Any system which supports payment card processing must comply with higher requirements, per PCI guidance.

  • 2048 bit or 4096 bit (in accordance with FIPS 140-2 §4.7.3)
  • UAB has contracted with InCommon for TLS certificates for all of UAB systems using PKI should use these InCommon certificates. InCommon certificates can be ordered here.
  • Self-signed certificates are not recommended, nor are the use of other Certificate Authorities (CA). If you need to use any of these, contact Enterprise Information Security with a request through AskIT.
  • Wild card certificates should not be used. If you need to use a wild card certificate, contact Enterprise Information Security through AskIT.

  • TLSv1.2 is modern and provides the safest encryption. The use of this protocol is strongly recommended.
  • TLSv1.0 and TLSv1.1 are acceptable. TLSv1.0 should be phased out as soon as possible.
  • SSLv2 and SSLv3 are not allowed for TLS encryption at UAB.

  • You must use FIPS 140-2 where required by compliance.
  • Use AES-256 or AES-128 for symmetric ciphers.
  • Use RSA-2048 or RSA-4096 for non-elliptic curve public key cryptography.
  • Use Diffie Hellman Ephemeral (DHE) or Elliptic Curve Diffie Hellman Ephemeral (ECDHE) for key exchange with forward screcy.
  • Use SHA-2 rather than MD5 or SHA-1 for signatures, etc.
  • You should use ciphers that provide greater or equal to 128 bits real security or 3DES.
  • You should order ciphers by highest strength first.
  • Export (low-strength) ciphers are not allowed.
  • You should include ciphers that provide Perfect Forward Encryption.
  • Cipher strength selection should prioritize between confidentiality and then performance.

  • You should only use Transport Layer Security where it is required to protect information.
  • You should not have mixed secure and not secure for Web applications. Use the single mediation model.

Recommended configuration for Apache 2

Make sure you add to the main 443 server, and there are no overriding statements in virtual hosts. 

#SSLHonorCipherOrder not a valid command in Apache 2.0, only use in 2.2 and 2.4 – anything older than Apache 2.0 should be disconnected from the network.

SSLHonorCipherOrder on


SSLProtocol all -SSLv2 -SSLv3

#gives perfect forward secrecy but saw odd things on www with this, may revisit after older browsers diminish in use.


Special thanks to Ed Harris for the recommendations for Apache 2.

The registry data files for Microsoft Windows Server versions 2003, 2008r2 and 2012r2 have been posted to the UAB IT software download site. These files contain registry settings configurations that have been tested and verified to conform to the UAB encryption standard. These files will assist system administrators in configuring their servers to meet that standard.

File MD5 Hashes


  • 2003std.reg  -  E1A7F5FC9AA6B3AEC4B1D9F2ED1EECD8
  • 2008r2.reg - 94CCC4AFD6D1E05A687B65EF382E5CFC
  • 2012r2.reg - 94CCC4AFD6D1E05A687B65EF382E5CFC

Special thanks to Jim Clark and Patrick Gustin for the significant efforts to build and test these configurations. 

  • HIGH: Encryption suites with key lengths equal to or larger than 128 bits. Included in this definition is the 3DES (Triple DES (Data Encryption Standard)) encryption suite.
  • MEDIUM: Encryption suites with key lengths that are less than 128 bit but not included in those categorized as “export”. Does not include 3DES.
  • EXPORT (LOW): Encryption suites with key lengths that are 64 bit or less.
  • Rivest, Shamir, and Adleman (RSA): RSA is one of the first practicable public-key cryptosystems and is widely used for secure data transmission.
  • Diffie-Hellman (DH): DH is a specific method of securely exchanging cryptographic keys and was the first specific example of public-key cryptography as originally conceptualized by Ralph Merkle.
  • Elliptic curve Diffie–Hellman (ECDH): An anonymous key agreement protocol that allows two parties, each having an elliptic curve public–private key pair, to establish a shared secret over an insecure channel.
  • Transport Layer Security (TLS): Cryptographic protocols designed to provide communications security over a computer network. They use X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with whom they are communicating, and to exchange a symmetric key.
  • AES128, AES256, AES: A specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology in 2001. AES is based on the Rijndael cipher developed by two Belgian cryptographers, Joan Daemen and Vincent Rijmen, who submitted a proposal to NIST during the AES selection process.  Implementations are available using 128 bit AES or 256 bit AES.
  • AESGCM: AES in Galois Counter Mode (GCM): These ciphersuites are only supported in TLS v1.2.
  • 3DES: Triple DES is the common name for the Triple Data Encryption Algorithm symmetric-key block cipher, which applies the Data Encryption Standard cipher algorithm three times to each data block.
  • DES: Once a predominant symmetric-key algorithm for the encryption of electronic data. It was highly influential in the advancement of modern cryptography in the academic world. Developed in the early 1970s at IBM and based on an earlier design by Horst Feistel. DES is now considered to be insecure for many applications. This is chiefly due to the 56-bit key size being too small.
  • RC4: In cryptography, RC4 is the most widely used software stream cipher and is used in popular Internet protocols such as Transport Layer Security. While remarkable for its simplicity and speed in software, RC4 has weaknesses that argue against its use in new systems. It is especially vulnerable when the beginning of the output keystream is not discarded, or when nonrandom or related keys are used; some ways of using RC4 can lead to very insecure protocols such as WEP.RC2
  • Pre-shared keys (PSK): Pre-shared key or PSK is a shared secret which was previously shared between the two parties using some secure channel before it needs to be used. To build a key from shared secret, the key derivation function should be used. Such systems almost always use symmetric key cryptographic algorithms.
  • Certificate Authority (CA): A certificate authority or certification authority is an entity that issues digital certificates.
  • Secure Sockets Layer (SSL): A protocol developed by Netscape for transmitting private documents via the Internet. SSL version 3.0 was released in 1996. As of 2014 the 3.0 version of SSL is considered insecure as it is vulnerable to the POODLE attack that affects all block ciphers in SSL; and RC4, the only non-block cipher supported by SSL 3.0, is also feasibly broken as used in SSL 3.0.


Computer systems running vendor-unsupported or end-of-life operating systems are potential security threats to the UAB campus network. Vendors do not provide security patches for unsupported systems, and these unpatched systems can be exploited by attackers. Such exploitations can result in disrupted experiments, corrupted research data and/or completely compromised systems.  UABIT reserves the right to disconnect these computers from the campus network to mitigate this data breach risk (see UAB’s Acceptable Use of Computer and Network Resources policy). UAB system administrators are responsible for maintaining the security of all information systems, per the campus Data Protection and Security Policy, which includes updating applications and operating systems.

Any operating system prior to Windows Vista, Server 2008, and Mac OS X 10.8 should be considered unsupported. 


The information in this guidance statement applies to all constituents internal to UAB.


We recommend that systems running legacy, unsupported operating systems should not be used. They should be disconnected from the network because of the significant security risk to the university’s network and environment. If the device is critical and cannot be turned off or disconnected, the device should be physically isolated from the university network. If disconnection and/or isolation are not possible, then an exemption and risk acceptance form will need to be completed, signed by the appropriate dean or vice president, and filed with Enterprise Information Security.

Unsupported legacy operating systems:

Windows Family

Windows 95/98/ME

Windows 2000

Windows 2003

Windows XP as of April 2014

Windows 2000 server

Windows Server 2003 as of July 2015

Mac OS X Family

Mac OS X 10.7 (Lion)

Mac OS X 10.6 (Snow Leopard)

OS X 10.5 (Leopard)

OS X 10.4 (Tiger)

OS X 10.3 (Panther)

OS X 10.2 (Jaguar)

Mac OS 9.x

Linux Distributions

Ubuntu 14.10

Ubuntu 13.10

Ubuntu 13.04

Ubuntu 12.10

Ubuntu 11.10

Ubuntu 11.04 and Prior

Ubuntu 10.10

Ubuntu 10.04

Ubuntu 10.04.4 LTS and Prior

Debian 5.0 (lenny)

Debian 4.0 (etch)

Debian 3.1 (sarge)

Debian 3.0 (woody) and Prior

Red Hat Enterprise Linux 6.5 after Nov. 30, 2015

Red Hat Enterprise Linux 6.4 and Prior

Red Hat Enterprise Linux 5.9 and Prior

Red Hat Enterprise Linux 4.7 and Prior

Oracle Linux 4.4 and Prior

Other Unix OS

AIX prior to 6.1

Solaris prior to 9 (SunOS 5.9)

 FreeBSD 8.4 and Prior (as of Aug. 1, 2015)


Questions can be directed to or, by calling (205) 975-0842.



Data Custodians must:

  • Abide by the Data Access Policy and the Data Protection Rule.
  • Be granted approval by the Data Steward before accepting, processing, storing, and/or transmitting data, especially when data is classified as Sensitive or Restricted/PHI by the UAB Classification Rule.
  • Follow all data handling and security requirements set forth by UAB policy and standards, along with any mandates set by specific data stewards charged with protecting UAB data.
  • Designate appropriate individuals with system administration responsibilities, ensuring that their role in securing the system is defined in their job description, and that they are trained in administration and security of the system.
  • Ensure adherence to UAB guidelines and procedures for protecting data as found in IT Security Practices.
  • Ensure compliance with all stipulations of this and other UAB policies and other legal and regulatory requirements including those related to dissemination of data (UAB's Information Disclosure and Confidentiality Policy) and disposal of computer equipment and systems (UAB's Equipment Accounting standards, and "Guidelines for secure disposal of media containing sensitive information").
  • Ensure that risk assessments are performed (including disaster recovery plans, backup and contingency plans) as required by HIPAA for all PHI. Risk assessment is recommended for all other sensitive or mission critical data.
  • Ensure that documentation of data resources created, used, or stored within their area of control is maintained.
  • Ensure that systems containing sensitive information are physically secured from unauthorized access.
  • Ensure that the department/unit follows procedures to mitigate all identified compromises or identified data security threats.
  • Ensure that actual or suspected data security breaches, especially when involving sensitive data, are reported to the Data Security Office immediately and that any recommended corrective action is implemented.
  • Ensure that non-UAB entities or contracted third party vendors handle data in accordance with UAB policies and procedures.
January 01, 2012

Policy Violations

While it is impossible to anticipate every possible violation, examples are provided below to assist in defining what is considered to be responsible and ethical behavior.  This list is not intended to be exhaustive; in general, any activity which does not directly contribute to UAB's mission may be considered inappropriate use. 

  • Commercial activities, advertising, or any other "for-profit" ventures not specifically approved by the UAB administration.
  • Sustained promotion of any non-UAB activity or venture, profit or non-profit, public or private, personal or commercial, without approval of the UAB administration.
  • Creating, displaying, or transmitting threatening, racist, sexist, or harassing language and/or materials.
  • Creating, displaying, transmitting, or obtaining obscene or pornographic materials or any form of content which violates state and/or federal statutes and/or local standards of decency.
  • Copyright and licensing violations including, but not limited to, providing or obtaining illegal copies of software or digital media (movies, videos, music, etc.) for which legal permission to distribute or possess has not been granted.
  • Vandalism or mischief intended to incapacitate, compromise, or destroy UAB or other facilities, resources, or services.
  • Forgery or attempted forgery of electronic mail or posts to electronic forums or any other act of deceptive labeling of the originator of an electronic communication.
  • Obtaining goods, services, or funds of any form via electronic means by using the name and/or credentials of another person or entity without their consent and knowledge.
  • Deliberately sending un-welcomed or off-topic messages to an individual or discussion forum. This includes continuing to send such messages after being asked by the individual or forum's owner/moderator to stop doing so even though the originator does not consider the material offensive or inappropriate.
  • Transmitting unreasonable quantities of data or messages to persons or groups without their consent or request.
  • Spamming or transmitting unsolicited material to a large number of individual persons and/or discussion lists, newsgroups, or other forums even though the material itself may not otherwise violate these guidelines.
  • Being a continued impediment to other users through mass consumption of computing or network resources after receipt of a request to cease such activity, even if the activity is not otherwise disallowed.
  • Transmitting without permission private information such as grades, medical records, financial data, or any other information that is protected by the Public Records Law or by legislation such as HIPAA, FERPA, etc.
  • Attempts to compromise computer and/or network security measures or providing information/instructions for how to do so.
  • Unauthorized, deliberate action which damages or disrupts a computing system or network, alters its normal performance, or causes it to malfunction. This includes intentional attempts to "crash" network systems or programs.
  • Attempts to gain unauthorized access to other systems on the UAB campus or the Internet.
  • Sharing of secure access credentials, such as passwords or private keys.
  • Attempts to guess, capture, "hack" or decrypt the secure access credentials of other users.
  • Attempts to possess, decrypt, or distribute data to which access has not been authorized.
  • Attempts to elevate system privileges or access without consent.
  • Unauthorized access of internal or external services through the use of stolen, guessed, hacked, copied, or discovered secure access credentials or other private data obtained without consent.
  • The willful or negligent introduction of computer "viruses" or other disruptive/destructive programs into the UAB network or into external networks.

Cardholder privacy is important to the University of Alabama at Birmingham (UAB).  To better protect the privacy of cardholder data, UAB provides this privacy statement explaining the security and handling practices of cardholder data in the processing of payment card transactions.  This privacy statement shall be made available at any point where personally identifiable cardholder data may be requested by a UAB PCI Entity (merchant). 

This privacy statement applies to all cardholder data collected by or submitted to a UAB PCI Entity, or on a UAB-maintained website.  UAB PCI Entities and UAB websites will only collect personally identifiable information and cardholder data voluntarily provided by cardholders and customers, and will only use that information for the specific purposes for which it was provided.  UAB will keep this information strictly confidential, and will not disclose, sell, or lease the information to third parties unless required by law, or with the written permission of the cardholder. 

As with most websites used for payment card transaction services, UAB web servers collect web session data used to analyze site trends and gather broad demographic data.  UAB reserves the right to collect certain technical information of customers such as operating system, IP address, web browser software, and URL data through the use of cookies or other technology not linked to personally identifiable information or cardholder data. 

UAB-maintained websites may have links to other third party sites used for payment card transactions.  These third party sites may collect cardholder data and personally identifiable information through the use of forms or cookies, or from the customer's web browser.  Cardholders and customers are strongly encouraged to review the privacy policies of all third party websites outside the control of UAB for their procedures for collecting, utilizing, and disclosing cardholder data. 

UAB has made significant investment in security measures employed to protect cardholder data under its control.  Access to acquired cardholder data and personally identifiable information is limited to only those personnel for whom there is an established business need to access that data. 

For questions, comments, or concerns regarding this privacy statement, or UAB procedures for securely processing, storing, or transmitting cardholder data, please contact the AskIT Help Desk at (205) 996-5555.  UAB reserves the right to amend this privacy statement at any time, and will post this privacy statement and any updates at