Auditing Authentication & Authorization in Banner Presented by: Jeff White & Timothy Hollar From Tennessee Department of Audit

Topics Banner overview Authentication to Banner & 3rd Party Apps Authorization to Banner & 3rd Party Apps

Overview of Banner Architecture Section 1

Banner Overview Higher Education Enterprise Resource Planning (ERP) system. Original vendor – SunGard Higher Ed Now supported by Ellucian Ellucian serves 2,400+ higher education institutions globally Ellucian was formally known as Sunguard and SCT. The Tennessee implementation of Banner is supported by the Board of Regents, UT Central office, and Ellucian contractors. Banner is used at almost all higher education schools in Tennessee. Other ERP systems used at higher learning institutions could include Peoplesoft or SAP IRIS.

Banner INB vs SSB Banner INB – Internet Native Banner The functional user Interface for accounting, human resources, and other administrative staff Banner SSB – Self Service Banner The web-based interface to Banner functionality for students & Finance reporting functionality Banner INB includes an application server and database server. The database and application is tightly integrated. Banner INB is generally only available on campus and preferably only available to employees on campus. Banner INB is a higher risk, with lower availability. Banner SSB includes a web server along with an application server and database server. Banner SSB is generally available anywhere there is internet. It is a lower risk, with higher availability.

List above is not exhaustive! Banner INB Overview Includes multiple distinct “systems” or modules: Finance Human Resources Financial Aid Advancement List above is not exhaustive! Forms within each module are usually designated by the first letter of the form name. Each module can be upgraded to different versions. Updates released by Ellucian can sometimes affect all modules and sometimes will be module specific. Other modules exist, such as Student, as well as other third-party applications can be used to add onto the functionality of Banner or replace an existing module.

Banner INB Architecture Distributed architecture generally includes: Application Server Database Server Job Scheduling Server Web Server (Luminis) This is not meant to be a comprehensive list – only the basics These servers can be placed in one data center, or spread among multiple data centers anywhere in the world. Hence the “distributed” name. We have seen many different configurations of these servers.

Banner INB Architecture JAVA Web Form (in browser) Application Server Information by Oracle for Oracle Fusion Middleware Forms Services: Index: http://docs.oracle.com/cd/E24269_01/doc.11120/e24477/toc.htm Oracle Forms: http://docs.oracle.com/cd/E24269_01/doc.11120/e24477/intro.htm#CHDGIAFC Other servers may exist, such as a job scheduling server or business warehouse or other applications interfacing with Banner INB. Oracle Database

3rd Party Applications SciQuest E-Procurement Touchnet U.Commerce Many available for varied purposes Common 3rd Party Apps: SciQuest E-Procurement Touchnet U.Commerce Third party applications can either be hosted by the school on their own servers, or hosted by the vendor/service organization. These third-party applications can either replace Banner INB processes or interface with Banner. Makes it difficult to audit Banner INB with a one-size fits all approach! Our review of Banner INB authentication and authorization will be primarily related to Banner INB and not third-party applications.

Authentication vs. Authorization Authentication The process of identifying a user – usually by a user name and password Authorization The function of specifying or granting access rights to resources in information systems A very important distinction when considering logical access to an application. Authentication and authorization can be handled very differently. The slide includes a definition of each term.

Authentication to Banner & 3rd Party Applications Section 2

Banner User Accounts When a user connects to Banner, that user also connects to the Oracle database All Banner INB accounts require individual Oracle database accounts. Banner SSB accounts do not work the same way. Banner INB authentication & authorization use Oracle database info & processes Security is configured by granting privileges to a User Profile in Oracle Banner SSB accounts are stored in a separate database “tablespace.” A database account is used as an intermediary between the SSB tablespace and the database account (wtaylor). NOT the same thing as INB/database accounts

User Authentication Details Oracle uses a User Name & Password to identify a user Stored encrypted in the SYS.USER$ Table Authentication requires one Oracle privilege: CREATE_SESSION Note: Oracle 11g uses SHA-1 hashing algorithm along with a “salt” to encrypt database passwords. Oracle 10g and earlier used a simple MD5/DES hashing algorithm

Banner INB Authentication Step 1 Enter user name/password Step 2 Oracle checks credentials Step 3 Oracle checks privileges/security rights: Default Role(s) Directly granted privileges PUBLIC account privileges (granted to everyone)

Method 1: Direct Login

Banner INB Authentication Method 1: Direct Login Oracle Database Password Profiles Login to App Server directly via web browser Method 2: Web-Facing Portal Directory Service Password Policies Login to Luminis web server first, then connect to App Server VS

Banner Direct Login Page Method 1: Direct Login Banner Direct Login Page Oracle Credentials Direct login means that you are provided the URL to the Oracle Fusion login and can access the login page with simply an Oracle username and password. Banner INB

Method 1: Direct Login Example URL: Uses the internet browser and Oracle Fusion Middleware Forms Service - a Java JRE Plug-in to display the Banner Forms in an Oracle Java Applet Example URL: http://APPPRD.ExampleCollege.edu:###0/forms/frmservlet?config=prod Information from Oracle for Oracle Fusion Middleware Forms Service: http://docs.oracle.com/cd/E24269_01/doc.11120/e24477/intro.htm#CHDGIAFC

Method 2: Web Server(Luminis) Active Directory Credentials or LDAP Luminis Web Server Login Banner Direct Login Page Oracle Credentials Web server login, means that you are using some other means of authentication to get to the login page and might also be using a single sign-on method. Banner INB

Method 2: Web Server(Luminis) Luminis Web Server can use a directory service for user authentication Login requires directory service credentials Possible to configure as Single Sign-On or as another layer of network security. Direct login via Oracle credentials may still be required!

Risks with Multiple Methods All paths to authentication should have proper controls if both methods are used! Method 1 Example: Both methods allowed, but only one has password controls & users most frequently connect via this method There is a risk if one of the methods being used can be circumvented. Banner INB Method 2

Oracle Password Profiles DBA_PROFILES PW Verify Function “IF” Function for password complexity V$PARAMETERS includes other security settings such as case sensitivity. PROFILE RESOURCE_NAME RESOURCE LIMIT DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD UNLIMITED PASSWORD_LIFE_TIME PASSWORD_REUSE_TIME PASSWORD_REUSE_MAX PASSWORD_VERIFY_FUNCTION NULL PASSWORD_LOCK_TIME PASSWORD_GRACE_TIME

Active Directory Password Policy

Active Directory User Account Control (UAC) UAC can override other group policy settings Codes to consider: Value Description 512 Enabled Account 544 Enabled, Password Not Required 66048 Enabled, Password Doesn’t Expire 66080 Enabled, Password Doesn’t Expire & Not Required

3rd Party App Authentication Authentication for each 3rd party application can vary. Must inquire about how authentication & security are configured. Also, consider network security such as Virtual Private Networks (VPN)

Examples – 3rd Party Apps SciQuest can be synchronized with Active Directory. Uses AD credentials for authentication Touchnet generally uses built-in security and authentication. Unique login URL for each user Unique Touchnet user IDs and passwords Touchnet has its own password controls

Take-Away’s for Auditing Look before you leap! Identifying relevant control points is key. Determine the layers of network security All Banner INB accounts can access the Oracle database directly – increases risk! Notes: Gaining an understanding of the “layers” of network security (if there actually are any) can affect the risk posed to the Banner INB application/database. The Banner INB application and its database are inherently subjected to more risk than a different type of application that is not as “tightly coupled” with its database. For example, all Banner INB users must connect to both the Banner application and the underlying Oracle database when they connect to “Banner INB”. Other applications – such as PeopleSoft which also uses an Oracle database – do not require application users to actually connect to the database itself (but instead, they connect to a web server which communicates with the back-end Oracle database through an application server). It is important to keep this concept in mind when auditing Banner since a “small” security problem could actually pose a much larger threat to a Banner/Oracle environment than other application/database environments due to the fact that there are many more avenues for accessing the Oracle database, and simply more users at the database level (even if most do not actually connect directly to the database through an SQL prompt routinely). Finally, it is also important for an organization using Banner to attempt to limit and/or monitor access to the Oracle database directly through an SQL prompt (or some other tool such as Putty, etc.) since all “application” users with access in the Banner INB application will have at least some level of privilege at the Oracle database level.

Authorization in Banner & 3rd Party Applications Section 3 Your system administrator has determined that your current activity is providing a level of enjoyment beyond that which is allowed on company time. Your enjoyment will now be disabled. You may continue with this activity, but you may not enjoy it. See your system administrator for more information.

Banner Security Oracle database security structures serve as “building blocks” Oracle security configuration can either strengthen or undermine security Database privileges largely determine what a user can or cannot do in Banner When a user connects to “Banner”, that user also connects to the underlying Oracle database

Banner Security Basics Banner uses “Role-based” security Banner “Roles” = Oracle Roles Containers for Oracle system privileges Can be password-protected A Banner “Class” is used to group Roles & database objects together in one container

Banner Security Basics Banner CLASS However, Banner objects can also be directly granted outside of a class; increases risk of security being undermined. Role (Oracle Privs.) OBJECTS A banner CLASS is like a container that holds groupings of Role-Object grants. Within a Class, Roles (groupings of Oracle Privileges) are associated with Database objects (this is a broad term that includes Banner “forms” and many other process and programs).

Banner Security Basics BANNER CLASS Role Access Level Banner Object/Form BAN_DEFAULT_M Read/Write FOMPROF FAAINVE BAN_DEFAULT_Q Read Only GSASECR Banner Classes are containers for Role/Object assignments Banner Classes are containers for Role/Object assignments. Users are assigned to Classes to stream-line security management

Banner Security Basics Users are assigned to Classes to stream-line security management Banner Class User User User User Banner security manuals recommend that security administrators use Banner classes to manage security instead of assigning all Banner INB users privileges and objects directly since this can easily become unwieldy.

Oracle roles are used in two different capacities in Banner Just “Role” with it! Oracle roles are used in two different capacities in Banner (1) Banner Classes When associated with “objects” in a Banner Class For Navigational Security “BAN_DEFAULT” (2) Default Roles Controls “default” privileges upon login Oracle security construct “USR_DEFAULT” A default role is invoked upon a user’s initial login to the database/Banner if it is NOT password protected (11g).

(1) Roles for Banner Classes Banner roles for Classes & Navigational Security: BAN_DEFAULT_M* Full read/write access BAN_DEFAULT_Q* Read-only access *These roles are created upon Banner installation with an encrypted password that no human knows!

(2) Banner Default Roles Banner-created Default Roles USR_DEFAULT_M Full read/write access USR_DEFAULT_Q Read-only access USR_DEFAULT_CONNECT Ability to connect to the database/Banner only; provides no navigational access *Note – none of these roles are password protected; more on that soon! Note: The “USR_DEFAULT” roles were created by the Banner vendor to address changes to certain role security functionality that occurred in the transition from Oracle 10g to Oracle 11g database versions. Oracle 10g: A user granted a password-protected role as DEFAULT would still be granted that role upon logging into the database; the user would NOT need to enter the password to “unlock” the role. Oracle 11g: A user granted a password-protected role as DEFAULT must enter that role’s password using the “SET ROLE” SQL statement before that role will become active for that user. Since the “BAN_DEFAULT” roles are password protected with encrypted passwords that no human knows, these roles are essentially useless as default roles and present no risk. The USR_DEFAULT roles were created for the explicit purpose of being used as Default Roles to circumvent this change in the way that Oracle handles default roles. However, these roles do present a potentially greater risk if assigned as a DEFAULT role since they will be “activated” when the user initially logs into the database.

Role Details – Oracle System Privileges USR/BAN_DEFAULT_M CREATE SESSION SELECT ANY TABLE EXECUTE ANY PROCEDURE SELECT ANY SEQUENCE UPDATE ANY TABLE SELECT ANY DICTIONARY DELETE ANY TABLE INSERT ANY TABLE LOCK ANY TABLE USR/BAN_DEFAULT_Q CREATE SESSION SELECT ANY TABLE USR_DEFAULT_CONNECT CREATE SESSION Connect Only “Read only” Access Oracle Roles act as containers for Oracle system privileges. Oracle system privileges are some of the basic “building blocks” of security permissions in the Oracle database. Oracle system privileges are pre-defined by Oracle and cannot be changed. Each system privilege allows an assigned user to perform one or more distinct actions in the database. Below are a few privileges of note: CREATE SESSION – allows a user to connect to the database, but nothing more. SELECT ANY TABLE – provides a baseline of “read-only” access System privileges with the word “ANY” in the name are generally more powerful privileges, and privileges like “UPDATE ANY TABLE” or “SELECT ANY DICTIONARY” should be assigned with care. These privileges provide full “write” access.

Banner Form Authorization Step 1 Navigate to a Banner form Step 2 Banner Checks for an Oracle role E.g. BAN_DEFAULT_M Step 3 Banner Checks for the “object” Step 4 Banner Decrypts Oracle Role Password This “activates” the role’s privileges only for that object Step 5 Access to object granted based on Role’s privileges E.g. BAN_DEFAULT_M = full read/write access

Banner Security & Default Roles Banner security manuals recommend that all users be assigned one Default Role USR_DEFAULT_CONNECT Assigning powerful roles as “Default” can create security risks Note: In Oracle 10g, if a user was assigned a default role that was password protected, that role (set as DEFAULT) would be automatically invoked/activated when the user initially logs into their account. However, in Oracle 11g, things changed so that password protected default roles must still be invoked manually with the SET ROLE SQL statement. This is why Banner introduced the USR_DEFAULT_M, USR_DEFAULT_Q, and USR_DEFAULT_CONNECT roles to be used as default roles. These roles are NOT password protected so that the privileges embedded inside these roles can be activated automatically when a user logs into their account. The BAN_DEFAULT_M, BAN_DEFAULT_Q, and BAN_DEFAULT_CONNECT roles ARE PASSWORD PROTECTED and thus cannot be used as default roles in an Oracle 11g database. These roles are created within the Oracle database upon the installation of the Banner application. When these roles are created, they are created with a randomly generated password that no human being knows (and the passwords are encrypted). Thus, because these roles are password protected with passwords that no one knows, no human can activate these roles as default roles with the SET ROLE statement. The implications of this condition are that users assigned BAN_DEFAULT_M, BAN_DEFAULT_Q, or BAN_DEFAULT_CONNECT as Default Roles will NOT have any access to the database or Banner through these roles being assigned as default roles since they are password protected. Thus, there is no risk associated with a user being granted BAN_DEFAULT_M as a default role since the user cannot invoke this role’s privileges. However, the USR_DEFAULT_M, USR_DEFAULT_Q, and USR_DEFAULT_CONNECT roles are viable to be used as default roles and will grant access to the database for users assigned these roles as default roles since they are NOT password protected.

Password Protected Roles Roles that are Password Protected in Oracle (11g) must be invoked at an SQL prompt, even if assigned as DEFAULT SET ROLE Statement with the password No user can manually invoke the BAN_DEFAULT roles because no one knows the system-generated passwords. Note: The BANSECR.GUBROLE table contains a listing of all database roles, and the passwords for those roles, that are recognized as usable in the Banner application. For more information about Oracle roles and passwords, see the following link: http://docs.oracle.com/cd/B28359_01/network.111/b28531/authorization.htm Also, the Banner 8.3 Security Administration Guide has the following (lengthy) explanation of roles and naming conventions that address the topic of passwords for certain roles: Role Naming Conventions The roles that can be created, maintained, and used with Banner objects must adhere to strict naming conventions. First, roles must begin with either BAN_ or USR_. (Only roles that begin with one of those two prefixes will be visible in the role maintenance tab.) Roles that begin with the prefix BAN_ will automatically be password-encrypted for use with a Banner object. Roles that begin with USR_ are not password-encrypted and may be given to users as default roles. This default role would then define the tables and views the user can write ad hoc reports against. The roles to be used with Banner objects must follow one of the following two patterns: BAN_DEFAULT_something or BAN_objectname_something. This standard is enforced in the security maintenance form. It is also implemented in the LOV that displays the roles that can be used with a specific form. The BAN_DEFAULT roles can be used with all forms while the BAN_objectname roles can be only used with the specific object. Both BAN_DEFAULT and BAN_objectname roles will be given a random password when they are created. Roles that begin with USR_ will not be given a password and must be used as user default roles, not roles to be associated with Banner objects.

Banner Default Role Risks Scenario #1 BAN_DEFAULT_M as a Default Role? Low Risk! BAN_DEFAULT roles are password-protected w/ system-generated, encrypted passwords. Notes: Since BAN_DEFAULT_M is created with a randomly-generated password that no human knows, end users cannot “activate” this role – meaning there is little to no actual risk associated with the assignment of BAN_DEFAULT_M (or _Q for that matter) as a default role.

Banner Default Role Risks Scenario #2 USR_DEFAULT_M as a user’s default role? Risky! Grants the user full write access to everything in Banner/Oracle that is not protected within another “schema” A Schema is “owned” by a database user & has the same name as that user. A Finance Department user granted USR_DEFAULT_M as a default role would probably have full access to all Finance department data, and the data of all other departments – with some exceptions. We have seen some organizations use an application called “Spreadsheet Budgeting” that managers/directors primarily used. This Spreadsheet Budgeting application required end users to have “Write” access to the underlying table(s) that the application interacted with. As a means of making the application work smoothly/easily, some organizations have granted their Spreadsheet Budgeting application users a default role of USR_DEFAULT_M so that those users can “fully utilize” the application’s functionality. However, some of these organizations had not even considered the risk of assigning their HR, Finance, or other personnel such high levels of access in Banner.

BANSECR & GSASECR BANSECR = default Banner security administration account Only BANSECR can access or execute the GSASECR (Security Maintenance) form “Distributed Security Administrators” can also access GSASECR Note: The GSASECR form is “owned” at the database level by the BANSECR account – this can also be understood as the GSASECR form is part of the BANSECR “schema” in the Oracle database. Only the BANSECR account, or other accounts with names that begin with “BANSECR_” may access the GSASECR form even if accounts are granted apparent access to the GSASECR form through Banner classes or direct grants. Thus, the naming scheme for Banner accounts should be controlled to ensure that no unauthorized users are given “Distributed Security Administration” privileges through the creation of accounts that begin with “BASNSECR_” (the account would still need to be given navigational access to the GSASECR form through Banner class(es) or direct grants of privileges).

Authorization in 3rd Party Apps Depends upon the application! Example: Touchnet & SciQuest use internal security structure Most 3rd Party apps are configurable to some extent. Gain an understanding of how they are used and what steps are controlled in Banner vs. 3rd party app. Both SciQuest and Touchnet have internal “security structures” that require the assignment of specific privileges based on a user’s job responsibilities. In SciQuest, the configurable “workflow” primarily controls the required approvals for a given purchase request, and users must be assigned the ability to approve certain purchase requests based on business rules and needs. Touchnet generally uses something equivalent to a “role” to assign privileges to end users (i.e. cashiers) but these should likewise be created and assigned based on business rules and users’ job roles.

Relevant Data for Audits Obtain security data for Banner/Oracle Key Tables Include: Obtain 3rd Party App security data May require coordination with the vendor Table Name Description DBA_USERS Listing of Database Accounts/Status DBA_ROLE_PRIVS All database accounts/default roles GUVUACC “Object Access by User View” = All Banner Accounts, Classes, Objects, & Roles Note: The listing of tables in this slide is not nearly comprehensive for a full information systems audit of all aspects of Banner security and especially Oracle security.

Take-Away’s for Auditing Determine who has access to BANSECR Evaluate accounts assigned USR_DEFAULT_M or _Q as a Default Role Evaluate users with access to make changes on other security forms like FOMPROF, Finance Security Maintenance Form Only the database administrator and/or designated security administrator should have access to (i.e. know the password to) the BANSECR account since this account has full access to the Banner security menus (GSASECR). Additional security administrator accounts can be created, called “Distributed Security” accounts, that begin with “BANSECR_”. Because these accounts have “BASNSECR” at the beginning of the account’s name, these accounts are “authorized” to access the BANSECR schema and the GSASECR (Security) forms. For example, if Tom works as a distributed security administrator for the human resources department, he may be assigned a secondary security administration account called “BANSECR_TOM”. Most user accounts should not be assigned USR_DEFAULT_M as a default role since it provides high levels of access (i.e. read/write) to most aspects of Banner and the Oracle database – but NOT the GSASECR form which is “owned” by the BANSECR account (the concept of a database schema protects the GSASECR form so that only the BANSECR account can access it). The FOMPROF, Finance Security Form, is where many Finance module-specific security settings can be configured – both at a global level and for individual Banner INB account. The FOMPROF Form can also be used to configure reporting access in the Banner Finance SSB system. Access to FOMPROF should generally be limited to the Finance department personnel designated/authorized to be responsible for managing security in the Finance department. Generally, the IT department personnel do NOT need to have the ability to make changes on FOMPROF if responsibility for managing the FOMPROF form is delegated to specific personnel in the Finance department.

Take-Away’s for Auditing User Authorization Documentation Consider how the entity documents user access: By Role/Object or by Class? Consider whether specific “access levels” (i.e. classes) are requested and that requests are not for access “like” an existing user. Note: In Banner, there is a built-in feature whereby the security administrator (i.e. the person(s) with access to the BANSECR account) can create a new Banner account that is a “clone” of an existing account. Because this feature exists and makes it very convenient to “clone” an existing user’s access to a new user, we have seen some institutions indicate on User Authorization Forms/Requests to provide a new user with access “like” an existing user. Best practices generally recommend that access level changes for system users be documented and that the specific levels of access are documented – not just a generalized statement to give Person B the same access as Person A. This practice may increase the risk of assigning a user excessive levels of access in the system.

Take-Away’s for Auditing Periodic Review/Reauthorizatioin Consider auditing how management monitors Banner access: Review of classes granted to users Review of terminated user access Review of objects granted directly to users Note: In Banner, there is a built-in feature whereby the security administrator (i.e. the person(s) with access to the BANSECR account) can create a new Banner account that is a “clone” of an existing account. Because this feature exists and makes it very convenient to “clone” an existing user’s access to a new user, we have seen some institutions indicate on User Authorization Forms/Requests to provide a new user with access “like” an existing user. Best practices generally recommend that access level changes for system users be documented and that the specific levels of access are documented – not just a generalized statement to give Person B the same access as Person A. This practice may increase the risk of assigning a user excessive levels of access in the system.

Final Thoughts Banner & Oracle are “tightly coupled” – creates security enhancements & risks. Banner security can be bypassed through poor Oracle database security Third-party applications may require extra audit effort to understand; don’t forget about SOC/SSAE 16 Audit Reports!

That’s All Folks! Questions? Jeff White – Jeff.White@cot.tn.gov Timothy Hollar – Tim.Hollar@cot.tn.gov