Authentication

Security Standard: Account Management

Security Standard: Account Management

Scope

This standard applies to all RIT Information and Information Resources.  

 

Requirements for All Accounts

The following security controls are required to be implemented on all accounts:

1.      Account Authentication

1.1.   End user account authentication should use the enterprise identity and access management service when the system or application processes Private, Confidential, or Critical Process information. 

1.2.   The use of the enterprise authentication service by an application should be authorized by the Authentication Service Provider and the security reviewed by the Information Security Office.

1.3.   Password Management

1.3.1.   Access to passwords and their hashes should be restricted, Therefore, public terminals and kiosks should not cache user passwords/passphrases

1.3.2.   All password changes should be logged, but the password itself should not be logged.

2.      Account Authorization

2.1.   Account authorization should use the enterprise identity and access management service or role-based account authorization native to the application when the system or application processes Private, Confidential, or Critical Process information.

2.2.   Data Owners should authorize:

2.2.1.   A process for approving and documenting authorization. Authorization granted to an account should be commensurate with the level of identity validation performed

2.2.2.   The parties who may approve user access to roles

2.2.3.   Roles and their privileges following the security principles of Least Required Access and Segregation of Duties.

3.      Account Provisioning

3.1.   Account Establishment: Each account should be for the individual use of a specific person with an academic or business need for this access.

3.1.1.   Employees who have multiple roles with the University should have role-based access provided such that when one of the roles is changed, the access for that role can be changed without impacting the other role. In the event this cannot be achieved technically, then separate accounts are required to fulfill the requirements of each role. 

3.1.2.   Student employees should have separate accounts from their student accounts. The student accounts may not have student employee-related access. 

3.1.3.   Physical access granted by student IDs should have a termination date pre-populated at the time of hire.

3.2.   Account Duration: Accounts are valid when the individual account holder has authorized access to the account or until the account is suspended by the University.

3.3.   Authorized Administrators should

3.3.1.   Review approvals and provision account/access

3.3.2.   Track authorizations, including:

  • Date of authorization
  • Identification of individual approving access
  • Identification of the role assigned (where applicable) or description of the access privileges granted.  The access privileges granted should only be used to fulfill assigned job duties.
  • These authorizations should be retained in accordance with the Records Management Policy (C22.0).
     

4.      Account Management and Maintenance

4.1.   Access Review:

4.1.1.   Managers are responsible for reviewing account and access privileges with the employee upon notification of job changes (e.g., termination, job changes). 

4.1.2.   Data owners of Private information identified by the ISO should review all accounts and access privileges at least annually to ensure that they are commensurate with job function, need-to-know, and employment status.

4.2.   Account Change Communication: Managers are responsible for communicating to account administrators when an account or access privileges may require modification or deactivation.

4.3.   Account Modification: Upon notification, the account administrators will review account and access privileges with the data owner or designee. All changes to accounts and access privileges should be approved and formally documented.

4.4.   Account Deactivation: Upon notification, account administrators are responsible for the immediate deactivation of accounts and access privileges when continued access is no longer required (e.g., terminated).  All deactivation of accounts and access privileges should be formally documented. 

4.5.   Account Lockout /Reset

4.5.1.   Authentication systems should disable user accounts after a set number of failed logon attempts.

4.5.2.   Administrators should follow established procedures for re-enabling or resetting user accounts once they have been disabled or upon request by the user. They should verify user identity prior to re-enabling or resetting user accounts. These procedures should take into consideration the potential risk to determine if automated procedures and the lockout time duration are appropriate.

4.5.3.   Administrators may not use the University Identification Number as the sole verification for resetting passwords.

 

Requirements for Special Accounts

The following security controls are required to be implemented on special accounts:

5.      Provisioning Administrator and Service Accounts: Requirements for issuing Administrator and Service Accounts are the same as other accounts with the following additions and changes:

5.1.   Account Establishment

5.1.1.   Ownership of an administrator account or group should be assigned to an individual. 

5.1.2.   Service accounts should be assigned to a system or application and are not for individual use.  

5.2.   Account Usage: Administrator and Service Accounts are specifically for system or application use only and should not be used for any purpose other than the administration or operation of the system or application. However, service accounts should be assigned to an account administrator.

5.3.   Group Access: Administrator and Service Accounts may be shared by a limited group of individuals for the purpose of operation and administration of the application or system, and only where required by the system or application. (In these cases, when possible, access to system accounts should be by methods that allow the individual to authenticate using a username and password.)

5.4.   Default Administrative or Service Accounts: Accounts that are part of the default setup of a system (including, but not limited to configuration access, database accounts, etc.)  should be removed, disabled, or changed (in that order) whenever possible. 

5.5.   Service Accounts: Service accounts should be reassigned and passwords of the service accounts changed when the account administrator is no longer in that role.

6.      Sponsored Accounts: Requirements for sponsored accounts are the same as other accounts with the following additions and changes:

6.1.   All sponsored accounts (for those who do not receive an account based on their role at RIT) with access to RIT information resources should contain an expiration date of no more than one year or the work completion date, whichever occurs first. Only authorized RIT account holders can approve sponsored accounts.

6.2.   Upon termination of the Sponsor’s account, the Sponsored account should be transferred to another appropriate RIT account holder or be deactivated.

7.      Generic/Shared Accounts:  Requirements for Generic/Shared Accounts are the same as other accounts with the following additions and changes

7.1.   Each generic or shared account should have a designated owner who is responsible for the management of access to that account. The owner should log access to the generic or shared account.

7.2.   Shared Generic Accounts: Generic accounts may only be shared in those situations where a system (server), device (switches or routers) or application cannot support the use of individual accounts technically. 

 

Effective Date: January 23, 2015

Standard History: November 11, 2013

Account Management Standard

Account Management Standard

The Account Management Standard provides requirements around creating and maintaining user and special accounts. The primary audience for the standard is account administrators. However, there are reporting requirements pertaining to personnel and roles and responsibility changes for managers as well.

Documented Standard

Current Account Management Standard (comply by 1/23/15)

Who does the standard apply to?

  • IT personnel who support account creation and maintenance for RIT information resources.
  • Managers reporting changes in access privileges/job changes of employees.

Key Concepts

  • Requires appropriate controls to ensure that users prove their identity and only have access to the resources to which they are authorized.
  • Provides requirements for managing and maintaining accounts accessing RIT information resources.
  • Provides requirements for special account types.

Resources

  • Checklist (coming soon)

 

Using LinkedIn’s New Two-Factor Authentication

Using LinkedIn’s New Two-Factor Authentication

The growing trend in sites adding two-factor authentication to their log in process has many feeling more secure in their social media and other online interactions.

With passwords being easy to compromise with phishing attacks, many users have been hoping for something more secure.  Two-factor authentication gives a double protection on your account, requiring you to know something (your password), and have something in your possession (a token).  The token can be any number of devices, cards or other physical items, often generating unique codes as proof you have the object.  Think of ATMs.  You need to have the ATM card (the token) and know your PIN in order to access your account and do any transactions at the ATM.  One without the other and you can’t get in.

LinkedIn is using a single-use code sent via SMS to whatever mobile number is listed on the account.  Your mobile device serves as your token.  This code is entered into the site after you enter your password to complete the two-factor authentication.  The idea behind this is if your password happens to be cracked or phished, as long as you don’t lose or compromise your phone, you are still safe from attackers logging into your account (though you should change your passwords and do a virus scan to be safe if your password gets compromised!).  

Want to enable this security feature for your own LinkedIn account? LinkedIn provides some instructions here:  
http://www.slideshare.net/linkedin/two-step-verification-on-linked-in.  

Many other sites have similar security features so check out your account settings and give yourself an extra layer of protection.

SECURITY NOTES:

As with any security chain, there are ways this could possibly be compromised.  The easy way is if an attacker knows your password and stole your phone.  A more sophisticated way is if you get phished for both your password and the code just sent to you, and the attacker users both before the code expires.  How likely could these happen?  Well that’s up to your security prowess.  Read more on our website about creating secure passwords (https://www.rit.edu/security/content/password), avoiding phishing attempts (https://www.rit.edu/security/content/phishing) and best practices when it comes to mobile device security (https://www.rit.edu/security/content/mobile-devices). 

Authentication Service Provider Standard

Authentication Service Provider Standard

The Authentication Service Provider Standard contains requirements for administrators, especially those using the RIT centralized authentication system.

Important

The Authentication Service Provider Standard will retire on January 23, 2015.

Effective January 23, 2015, the Account Management Standard will supersede the Authentication Service Provider Standard.

Server Security Standard

Server Security Standard

The Server Standard provides requirements for server configuration and use at RIT.

A list of ISO-approved security assessment tools, HIPS programs, secure protocols, and a sample trespassing banner can be found in the Technical Resources

What does the standard apply to?

All servers (including production, training, test, and development) and the operating systems, applications, and databases as defined by this standard.

The standard does not apply to individual student-owned servers or faculty-assigned student servers for projects; however, administrators of these servers are encouraged to meet the Server Standard.

Recommended Strong Authentication Practices

The RIT Information Security Office recommends that all systems requiring strong authentication

  • comply with RIT's password and authentication standard (REQUIRED)
  • use a complex password of 12 or more characters. Fifteen or more characters are preferred.
  • use multi-factor authentication such as:
    • tokens
    • smart cards
    • soft tokens
    • certificate-based authentication (PKI)
    • one-time passwords (OTP)
    • challenge / response systems
    • biometrics

Approved Vulnerability Scanners

Nessus, Nexpose, and NMap are approved for scanning servers at RIT. For information on the scanning conducted by the RIT Information Security Office see the Vulnerability Management Program at RIT.

Approved Encryption Methods

See Encryption at RIT for approved encryption methods.

Server Security Standard

 

Subscribe to RSS - Authentication