Application Administration

Application administrators play a very important role in securing college systems.  Below is a set of guidelines, or best practices, to help you configure the application you manage and ensure you are protecting the data you handle.  

Not sure who is the administrator to your application? Let us know!

Security Roles

Security roles in applications determine who can access what type of information in your application, as well as what they can do with the information (ie: view, edit, manage). By default there is always an administrator, or super user, account built-in to all applications in order to configure the application for use. This account is very powerful and can do anything in the application. It is the responsibility of the administrator to create security roles, or sometimes called groups, in the application to govern data access.

When creating security roles, it is important to consider what type of data is stored in the application, who needs to access that data, and what type of actions will be performed on the data. You should only grant access to data that is absolutely necessary for the user to perform their job duties, which will reduce the risk of exposing information unnecessarily and also reduce the impact of human error. When you have more privileges in a system, making an error can cause a larger impact.

There are four general categories of user roles and their capabilities:

• Administrator (super user) - create, edit, delete security roles, users, data, fields, records;
• Privileged - create, edit, delete data, fields and/or records;
• Standard - create, edit data and/or records (or subset);
• Limited - view data and/or records (or subset);

The principle of least privilege (POLP) is the practice of limiting access rights for users to the bare minimum permissions they need to perform their work. Under POLP, users are granted permission to read, write or execute only the files or resources they need to do their jobs: In other words, the least amount of privilege necessary.

Authorization is the function of specifying access rights or privileges established with security roles.  Application administrators must monitor and maintain security roles as personnel, business processes, and functionality of the application changes.  All of these events may cause a need to create new security roles and/or to re-evaluate existing ones. 

Accounts and Authentication

How user accounts are managed and how users will login, or authenticate, to your application is another important decision for application administrators.  By default there is always an administrator, or super user, account built-in to all applications in order to configure the application for use. This account is very powerful and can do anything in the application. This account (username and password) only exists in the application.

There are two main differences in account types, one is local to the application and one is not. 

• Local Accounts - created by application administrator or privileged user; username and password only exist in application; created by self-service process (user sign-up);
• Dynamic Accounts (LC) - created by a third party authorization procedure (use LC single-sign on* to login); username exists in application; password exists in third party service that is integrated with LC Account systems;
• Dynamic Accounts (non-LC) - created by a third party authorization procedure (use personal Google or Facebook to login); username exists in application; password exists in third party service (use personal Google or Facebook);

What will be used for the username (email address vs. login), where it is stored (at service provider or with a third party), how much administrator effort will be required to maintain users and their passwords are all part of application administration.

Local account passwords will be stored and managed by the application.  This means you may have a password policy that governs the length and complexity of your passwords for your application, separate from LC systems.  Passwords that are stored in third party services such as your personal Google account, Facebook or LinkedIn, and excluding LC’s single-sign on service, are not under your control.

*For ease of user administration and for continuity of operations, it is highly recommended to leverage LC’s single-sign on (SSO) service.

Interested in LC’s SSO for your application? Let us know!

Multi-Factor Authentication (MFA)

Practicing good account security entails creating long and complex passwords that are unique to every application.  It is also important to keep your passwords private and not to share them with anyone (even IT!).  Employing this best practice amounts to a single layer of defense, which may not be enough to protect very sensitive data like a social security or bank account number, or to protect an administrator or privileged account.

Multi-factor authentication (MFA) provides additional layers of defense by requiring more than just a password (single factor), but also requiring something else.  This something else can be something you have (SMS code on a paired device), somewhere you are (IP address), or something you are (biometric).

Some applications have their own MFA** capabilities and it may be prudent to enable them.  As an application administrator you will be responsible for managing and trouble-shooting any issues that may arise.

**For ease of user administration and for continuity of operations, it is highly recommended to leverage LC’s multi-factor authentication (MFA) service.

Interested in MFA for your application? Let us know!

Secure HTTP (https)

Configure SSL protocols

Administer Support

Provide Subject Matter Expertise (SME) on application
Maintain system documentation
Provide training to end-users - may include ‘customers’ (non-staff users of application)
Troubleshoot, resolve and document any reported problems
Be fully responsible for problem management activities such as issue resolution and root cause analysis
Liaise with vendor support on all issues, license and/or maintenance renewals
Establish best practices for application use

Administer the Application and Data

Decide which data will populate the application - this may include manual/automated imports
Populate application with data (working with IT for institutional data integration where necessary)
Set up and maintain process automation
Monitor the application
Publish a maintenance schedule for end-users, and affected application administrators of other systems with which your application is integrated
Lead and participate in efforts to implement application updates to include upgrades, patches, and new releases
Provide application performance tuning
Collaborate with vendor and/or institutional technical teams to ensure proper integration of the environment
Plan and coordinate testing changes, upgrades, and new services, ensuring systems will operate correctly in current and future environments
Develop test plans to verify logic of new or modified programs
Develop and maintain the reporting and dashboard infrastructure for end users

Manage Governance and Continuity

Recover lost data as a result of our error or system compromise
Retrieve and deliver application access logs to ISO for incident response or legal investigation
Get appropriate approval, signed agreement by General Counsel for legally protected information
Manage vendor contract

 

Training

Complete Security Awareness training course when prompted by IT