Five Important Questions to Answer for a Sound Banner Security Policy

At SIG, we know how important it is to have a great security policy to keep your institution’s data safe. That’s why we put together detailed guidelines you can use to adjust, re-write, or create a policy that will steer your Banner and connected systems in a safe and secure manner. Questions to be answered by a policy and implementation doc include: 

1. What does the policy apply to? In many cases, the data and not the system should be the real focus. That policy would then apply to the core student information maintained by Banner and connected systems.
2. Who can access Banner data and when? This should probably be general at the policy level and highlight the characteristics of a job that requires access to areas of information. At this point, you may wish to make a distinction between having the ability to access one person at a time (typically done in Banner screens) versus the ability to see or update information in groups (typically done through reports or some type of mass update process). The different levels of access may require different training or considerations of risk. 
3. What data can be accessed? At the policy level, this should define the idea there are two types of access—application and data. In an application (for example Banner) we define the objects that can be accessed (Forms/Pages/Jobs/Reports) and the type of access (Query/Modify). Separately is the question of which populations can be accessed within a given object. In Banner, this is managed using Fine Grained Access Control (FGAC) or row level access.
4. An Implementation Document can specify the exact details of how the policy will be implemented, including specific forms and procedures. The key questions it should answer include: 

• Does FGAC need to be implemented to prevent unauthorized access before it happens, or can a robust system of auditing and alerts be used to ensure an individual does not open records they are not permitted to? This answers the question of whether PII security is needed, or, if an audit system such as Banner Data Defense (BDD) would be sufficient. Are both needed to provide separate security functions? 
• How does an employee request access? Who starts the request; who approves the request (there may be multiple layers, and this may vary by the nature of the request), and who grants the access in the system? 
• How will access requests with approvals be tracked, and compared against Banner to ensure compliance? This is where automation can be very useful. 
• How long is access granted for? Or, how often must it be reviewed and renewed? 
• How will usage of Banner be tracked and audited? 
• What training is needed for data security and privacy? This is not Banner specific but applies to all information held by the institution. 
• What training is needed for data integrity? This is Banner or system specific and seeks to define how users are trained and monitored to ensure data is accurate and properly maintained. 
• Some institutions automate part of the provisioning process upon hiring based on data in the HR System (which may be Banner). This type of automation should ensure the process not only provisions user accounts, but also de-provisions access in a near real-time way. 
• What criteria should be used by approvers to determine whether to grant or deny a request? 
  • When a request is denied, can it be returned for correction (which complicates the process) or must it be submitted as a new request with the changes needed (which might be more work for users, but ensures a clean request from start to finish)? 
  • Is there an effective way to guide users to requesting the right access initially to help reduce the likelihood of a denial?

5. How does Authentication, Authorization, Access, and Auditing fit into this process and documentation? 

• Authentication –Takes place outside of Banner using SSO. Both CAS and SAML2 are now supported by almost all Banner applications and an SSO provider is required for Banner 9 applications. Because other applications have access to Banner data, consider requiring those applications to support SSO, use the same authentication provider as your SSO system, or meet the same standards for password protection (complexity, age, re-use, ability to reset, etc.). 
• Authorization – This is handled by Banner when accessing Admin and Self-Service applications. When possible, satellite applications could use the same systems and techniques to ensure the process is consistent. More importantly, you should seek to ensure that any application that interfaces with Banner data can provide the same level of controls and be managed by the same methods.
• Access – This is managed by each application. Banner manages access through a combination of Oracle roles and a system of object assignments (including classes and groups). Additionally, there are three types of FGAC which can be implemented:  
  • VBS – Value Based Security – The value of a field determines whether a user can perform SELECT, INSERT, UPDATE, or DELETE operations. 
  • PII – Personal Identity Information – If a PIDM is a member of a group (student, faculty, employee, etc.), the user must have permission to access the group. 
  • Masking – A field on a form can be hidden, partially masked, or fully masked. 
  • Audit – Some Banner auditing features are available with baseline Banner but must be turned on by an administrator. This is considered a security best practice and should be enabled and monitored. If additional auditing is needed, Banner Data Defense (BDD), which includes an implementation of Oracle Transparent Data Encryption (TDE), can be used to provide database encryption, session encryption, and an audit vault for tracking detailed access. 

If not defined in other policies, an incident response policy which defines procedures, communication plans, and escalation methods should be created as part of the security policy and procedures. If you’re struggling to put together a sound policy, let’s discuss how SIG can help!