The Microsoft Outlook mobile app will be blocked from accessing UAB mailboxes as of noon Thursday, Feb. 26, 2015, because of security concerns. Individual users of the app will be notified.
UAB IT’s Enterprise Information Security team has determined that the Microsoft Outlook mobile app violates UAB’s Password/Passphrase Standard because it caches BlazerID passwords in a cloud service — posing a serious security risk.
UAB IT will be blocking the Microsoft Outlook mobile app from accessing UAB mailboxes, so you won’t be able to receive email through the app. The Outlook mobile app is essentially a rebranded app from a company called Acompli, which Microsoft purchased recently. Many universities and other entities are also taking the step to block the Outlook mobile app.
Native mail applications on iOS and Android are still safe for use.
  • Discontinue using the Outlook Mobile App and uninstall it from your device.
  • Change your BlazerID Password
  • Configure the standard mobile app for use with Exchange (employees) or Office 365 (students). 
p.
{slide=What does "caching in the cloud" mean?}The Outlook mobile app captures each user’s BlazerID and password and stores them in a cloud service. UAB has no contract with — nor a security assessment from —the service, so UAB IT has no way of guaranteeing the safety of those BlazerIDs and passwords.
An official copy of this standard can be found in the UAB Policies and Procedures Library and on the UAB IT Information Security website in the IT Related Policies and Guidelines pageUAB’s password/passphrase standard states that applications should not cache BlazerID passwords/passphrases without an approved exception.
If you need help setting up a new mail app on your phone or mobile device, please contact AskIT@uab.edu or phone 205-996-5555.
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.
  • 2048 bit or stronger (in accordance with FIPS 140-2 §4.7.3)
  • Self-signed certificates are not recommended. 
  • UAB has already paid for InCommon certificates. If you need to use another Certificate Authority (CA), contact IT Security with a request through AskIT.
  • If you want to use a wild card certification, you must receive permission from IT Security through AskIT.
  • TLSv1.1
  • TLSv1.2
  • SSLv2 and SSLv3 are not allowed
  • TLSv1.0 should be phased out
  • You must use FIPS 140-2 where required by compliance.
  • 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.
  • If there is no protection required, consider using a service configuration that does not use TLS.
  • 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

SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!ADH:!SSLv2:!EXPORT56:!EXPORT40:!RC4:!DES:!LOW:RC4-SHA:RC4-MD5:+HIGH:ALL

SSLProtocol all -SSLv2 -SSLv3

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

#SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW

  • 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.
October 28, 2014

IT Risk Bulletins

Each month, the chief information security officers for UA, UAB, UAB Medicine and UAHuntsville publish a monthly electronic newsletter to help users avoid IT errors.

February 2015 | Issue No. 5

January 2015 | Issue No. 4

December 2014 | Issue No. 3


November 2014 | Issue No. 2

October 2014 | Issue No. 1
As part of the University's contract review process, UAB IT is responsible forcontract reviewing any University contract that includes an IT or IT related component prior to such contract being executed.  The information and sample addendum, below, provide details on how to ensure that your IT related contract can be routed for execution in a timely manner. Questions on the process or requirements should be directed to UAB IT
 
What constitutes an IT related contract or agreement? (see note below about renewals)
 
  • Contracts* for software, subscriptions, or services (including software maintenance) that include  
    • Hosting/processing/transmission of UAB data external to UAB
    • PCI (Payment Card Industry) acceptance/processing of credit card transactions
    • Design, creation, maintenance, support, and/or hosting of any website/webpage
    • Personally identifiable information (PII) or personal health information (PHI) - does not include Health System Agreements which are managed by HSIS
    • Audit language
    • Custom software development
    • Hardware purchase with embedded software with any of the above
  • *NOTE: For agreements that include the type of information listed above, documents/agreements must be executable, meaning they have signature lines for both UAB and the vendor.  Printing a 'click-agreement' or printing language from a website and submitting as an 'agreement' for review does not guarantee that the vendor will ever see changes/addendums that UAB may make or add to the agreement. 


What can I provide my vendor in advance so they are aware of the contract requirements?

  • For most agreements the following two addendums will be added during the routing process.  You can provide those addendums to your vendor in advance for their review and acceptance/signature prior to routing at UAB and include them in the routing packet.  
    • The general UAB Addendum (found on the Financial Affairs contract website) which covers information related to State, University, and Legal issues/clarifications.  Any changes to the UAB addendum must be approved by University Contracts.
    • The UAB Information Technology Addendum which covers additional confidentiality, information security, and liability language to mitigate any issues related to the items/concerns above. Portions of the IT Addendum may be applicable to only certain agreements and that applicability is detailed in the various sections of the addendum.  Any changes to the IT addendum must be reviewed and approved by UAB IT. 
  • For agreements that include HIPAA (health related information) a Business Associate Agreement (BAA) may also be required. For information related to the BAA see the UAB HIPAA website

 

What do I need to ensure is included in my routing packet to UAB Contracts?
 
In addition to the requirements shown on the Financial Affairs contract review process website the following items are needed to ensure a timely review:
  • For RENEWAL agreements*: please ensure that a copy of the original, underlying, governing agreement that was previously executed between UAB and the vendor is included with the routing packet, including any subsequent addendums.  If that original agreement included the IT Addendum and UAB Addendum, no additional language may be necessary as long as the renewal document references the original agreement and not a new document. If the original agreement did not include the IT Addendum, please have it reviewed/executed by your vendor and attach to the renewal agreement when routing.
  • For NEW agreements:* please ensure that a copy of the full, underlying, governing agreement (license, EULA, professional services, etc) and any documents referenced in such agreement such as separate maintenance, support, privacy, statement of work, etc. are included with the routing packet.  Submission of an order form, quote, schedule, etc. without the full underlying terms/conditions document will cause delays in the review process as those documents will be requested before the review can be completed. In addition, please have your vendor review/execute the UAB Addendum and UAB IT Addendums and attach them to the new agreement when routing. 

*NOTE: For agreements that include the type of information listed above, documents/agreements must be executable, meaning they have signature lines for both UAB and the vendor.  Printing a 'click-agreement' or printing language from a website and submitting as an 'agreement' for review does not guarantee that the vendor will ever see changes/addendums that UAB may make or add to the agreement. 

 

Link to UAB IT Addendum

UAB has contracted with DriveSavers to provide data recovery services for the UAB
community. DriveSavers is the only data recovery company in the industry that undergoes
annual SAS 70 Type II Audit Reports and is HIPAA compliant, offering the highest level of data
security available. DriveSavers is also compliant with FAR 52.224-2 (Privacy Act), ISO 17799,
Sarbanes-Oxley Act of 2002 (SOX), the US government Data-At-Rest (DAR) mandate, the
Gramm-Leach-Bliley Act (GLBA) and the new regulation by National Institute of Standards and
Technology, NIST SP 800.34 (Rev. 1).


To view DriveSavers certifications, and learn more about Data Recovery Industry standards,
visit: http://www.drivesaversdatarecovery.com/proof


Order Data Recovery Services click & follow instructions.

Report an Incident Now 

  1. Isolate the device

    Make sure the system is disconnected from the network. This is to protect UAB from any additional impact from the incident.

  2. Determine the affected data.

    Confirm whether or not sensitive data was housed on the compromised device. This includes employee, student, patient, or research data. Determine if any sensitive data was inappropriately accessed. If so, immediately escalate to both your local management and the UAB Data Security (https://silo.dso.uab.edu/incident or call 205-975-0842).

    If sensitive data is at risk, do not perform additional activity until you have spoken with Data Security.

  3. Perform Root Cause Analysis

    Establish the reason that the system was exploited.  Ask yourself these questions:

    • Did an end user install something harmful?
    • Was it caused by a weak password?
    • Was the system missing a patch?
  4. Remediate the issue

    The best way to restore a compromised machine is frofm a trusted backup or to do a clean installation. Even what used to be routine virus infections have become so advanced that we cannot trust a system once it's been infected.

    Perform password changes for end users and any administrators that may have used the system as well. This includes BlazerIDs and other accounts such as websites that were accessed from the compromised machines. Local Administrator passwords should also be changed.

  5. Reconnect to the network

    Once the system has been properly remediated, UAB Data Security, in conjunction with the HIPAA Security Office, will reconnect the machine to the network. This process can take up to 24 hours after the initial request.

    If you receive a notice saying the machine was compromised, the best way to get reconnected is to reply to that email.

    Otherwise, Please call 205-975-0842 or email DataSecurity@uab.edu for assistance.

January 01, 2012

Antivirus Software

UAB IT provides Antivirus for use by everyone at UAB including your personal home systems. To download Microsoft Forefront Anti-virus software(Windows) or Sophos Anti-virus (OS X), please click the link below and select from the available antivirus titles.

Please Note: There is a known incompatibility with Sophos and FileVault on Mac OS X 10.5.x. If you are using FileVault please do not install Sophos Antivirus at this time.

Order Now

January 01, 2012

Secunia PSI

Secunia PSI is a security tool designed to detect vulnerable and outdated programs and plug-ins. These vulnerabilities expose your PC to attacks which are rarely blocked by traditional anti-virus due to the fact they exploit programs already on your computer and are therefore increasingly "popular" among criminals. Order/Download Now

The only solution to prevent these types of attacks is to apply security updates, commonly referred to as patches, to every piece of software and plugin on your system. Finding and applying these patches is a tedious and time consuming task. Secunia PSI automates identifying vulnerable software and alerts you when your programs and plug-ins require security updates. Secunia PSI will also alert you when software reaches the end of a support life cycle and may require an upgrade.

Note:  The default installation of the PSI client automatically updates Java and will automatically install updates that may cause incompatibilities UAB systems including Blackboard Vista, Oracle HR/Finance, and Banner.  

There are two methods of configuring PSI and working with automatic updates.  Please choose the appropriate one.

  1. Update Approval before Automatic Updates (Risk is not reviewing Secunia)
  2. Automatic Updates and ignoring Java (Risk is ignoring java)

Update Approval before Automatic Updates

Execute the PSI installer, click Next and then accept the License Agreement.

On the screen marked "Auto-Update Configuration" check the box "Require user-interaction before each Auto-Update"; click Next.

Click Next through the remainder of the install screens and click "Finish."

After installer finishes launch the PSI client.

The client will immediate start a scan.  Close the popup and wait for the scan to finish.



Scan results will likely show that there are insecure programs present.





Approving Updates

For software that has pending updates.  Those updates can generally be applied by left clicking the Approve Update link at the right hand side of the scan results page.  Sometimes the software cannot be automatically updated and will require the user to download and install the update manually.  In this case, clicking the update link will direct the user to the appropriate website to download the patch.

Ignore Java Updates and allow unprompted automatic updates

This configuration can leave Java as a risk that will never be identified.  However, it will automatically update many packages without user interaction.

Execute the PSI installer, click Next and then accept the License Agreement.

On the screen marked "Auto-Update Configuration" check the box "Require user-interaction before each Auto-Update"; click Next.

Click Next through the remainder of the install screens and click "Finish."

After installer finishes launch the PSI client.

The client will immediate start a scan.  Close the popup and wait for the scan to finish.



Scan results will likely show that there are insecure programs present.

View the scan results and take note of the location of the unpatched version of java and any other programs that should not be automatically updated.

Expand the Configuration menu on the left and select “Settings.”

Select the “Ignore Rules” tab at the top of the configuration screen.

Select “Create Ignore Rule” and name it java (or whatever program needs exclusion). Enter the location to the program in the box labeled “Rule Path”.

Clicking OK should immediately exclude the program from the scan list.

Finally, re-enable auto-updates for all programs that are not excluded. Select the PSI Settings tab and uncheck “Prompt before running automatic program updates.”

The computer will now update installed software automatically.

January 01, 2012

Encryption

PGP Whole Disk Encryption software (or FileVault for Macs) is designed to provide an additional layer of security for your data. Encryption is required for laptops used for UAB Business, and it is highly recommended for desktops in theft-prone areas. PGP software essentially "locks down" your hard drive, making the data accessible only to you and those you authorize. The disk encryption, in conjunction with logon and screensaver passwords, protects UAB data if the computer is lost or stolen.

Encryption Methods:

 

Additional PGP Documentation:

 

Do you use your laptop for UAB business?

Do you provide your own tech support?

Has your laptop been encrypted?

If you answered yes to the first two questions but have not encrypted your laptop, you are encouraged to take advantage of the options listed below to protect UAB data by encrypting your laptop.

HSIS Customers: Please contact the Health System Information Services (HSIS) Help Desk at helpdesk@uabmc.edu or 205-934-8888 for assistance with laptop encryption.

AskIT Customers: Please choose from the options listed below or contact the AskIT help desk at 205-996-5555 for assistance with laptop encryption.

Laptop Encryption Options:

Option 1 - Option 1 - Let Us Do It For You-!
This option requires that the laptop is dropped off at one of our locations for at least 1-2 business days.  The following procedures will be performed on your machine:

  • Backing up your data
  • Verifying or installing antivirus software
  • Updating antivirus definitions and scanning for viruses
  • Scanning with hardware diagnostic software
  • Installing operating system updates
  • Defragmenting the hard drive
  • Encrypting your laptop

Option 2 - Do It Yourself: "How-To" Documentation & Training Videos 
This is a do it yourself option. Please refer to the documentation and training videos on the following topics for information on how to configure and encrypt laptop computers. 

  • How to create a strong password
  • How to configure your laptop
  • How to scan for missing patches
  • How to update applications
  • How to install OS updates
  • How to install antivirus
  • How to backup your machine
  • How to defragment your hard drive
  • How to run SpinRite hardware diagnostic software
  • How to encrypt your laptop

Please feel free to contact us with any questions through our help desk, AskIT, by email or phone at 205-996-5555.