Skip navigation.
New Mexico State University

Security, Policies & Guidelines

 

NMSU Institutional Data Security Guidelines


Rationale

Based on the NMSU Institutional Data Security Policy, these policies are followed:

 

Banner Server Security and Sensitive Transactions

Along with desktop security of institutional data, the security of the servers must also be maintained.  This security includes the use of vendor security systems as well as system level security to include firewalls and virtual private networks

 

General Oracle Security

Banner is built using an Oracle database.  SCT is the prime architect for how the data is architected in Oracle (as they are the ones who specify the schema owners, tables and columns).  SCT relies upon oracle security to provide security to the database.

Remote access to the SCT Banner Oracle server is completely through an ODBC listener at port 1521.  For the vast majority of users, their access is through either Self-serve or Internet Banner.  Both access methods use front-end software to focus/limit the user’s access to activities relating to that form. For example, a form which deals with adding a person has been programmed to interrogate tables about people and may also add data into the tables about people.  Access to these forms is limited on a per person basis and hence access to the table information is also limited.

SCT also has a level of security at the “module” level.  For Human Resources and Finance, it is possible to limit what a user sees in a form.  For example, a departmental secretary in Computer Science could be set up to have access to HR and finance data for the Computer Science Department.  It should be noted that users who are in the central offices (like purchasing, payroll, etc) normally have access to all data in a module (e.g. Business office has access to all finance transactions).

 

Server level security

The main oracle server resides on a SUN SPARC based architecture running Solaris 9.  Automatic updates are run on all servers to ensure prompt application of vendor supplied fixes.  TCP wrappers are used to limit remote access to administrative ports like SSH and SCP.  Telnet is turned off.  FTP is limited to the mainframe and known hosts which provide data sources for the regular operation of the banner system.  Port 1521 (ODBC) is fire walled at this time to all campus users (see below for future action).  Users with the appropriate password can establish a session to query data.  A limited number of accounts have the ability to query the server and only a couple of accounts have the rights to update data. In all cases, the users who have access to the database have specific job requirements to have this sort of access (e.g.. IRP, ICT, FSA in Business and Finance). All default passwords delivered by SCT banner have been changed.  User passwords expire every 120 days.

Row level security via ODBC is not implemented at this time.  SCT does not recommend this level of security for Banner 6.

 

Network Firewall

ICT is in the midst of deploying a CISCO PIX firewall.  The PIX firewall will limit the access of port 1521 to the specific authorized users via a VPN.  This will eliminate the possible on-campus hacker attempting to make connections to our database via the 1521 port. Authorized access will require the user to have VPN software, a login and password for the VPN and a separate oracle login and password.

 

Oracle Reports

As part of the SCT product offering 16 finance reports are provided using oracle reports.  This offering requires that the user needing these 16 reports have full query access to the finance tables to operate properly.  Users of these reports may be able to pull data from finance areas not within their assigned finance module security using the supplied oracle reports.  In most cases, these users will not have access to the 1521 port unless authorized via other job requirements.

 

ODS

Selected data elements from the banner system are migrated to our data warehouse.  The data warehouse is called Operational Data Store (ODS) by SCT.  Any finance security engineered in SCT banner is not migrated over to the ODS.  ODS access is managed at a per table basis. Users who have direct access to the tables (via port 1521) can see all data in all tables.  Row level security is not implemented in ODS at this time.  There are a small number users who have direct access to the ODS – all of whom work in one of the core reporting areas (ICT, Institutional Research, Business and Finance).  End users will have filtered data based on their security roles established in the banner system.

Development

NMSU maintains two additional environments for development in which institutional data is retained.  Access to these environments is limited to the ICT development team and core function users. However, it should be noted that all transactions are on these development environments.

 

Assessment of sensitive transactions

A number of questions have come up concerning specific transactions (finance and HR) that may have a more sensitive nature.  Specifically: is SCT Banner and SCT ODS engineered in such a way to limit the access of this data to authorized personnel?

The following areas have personnel who have unfettered access to this data:

  1. IT development staff have access to the database and all data in the tables.  They use tools to analyze broken transactions
  2. Report Writers --  Technical staff who write reports typically have access to all data, SCT does not provide any logical manner to limit the report writers from sensitive transactions.
  3. Core users – Purchasing officers, budget directors, etc, have access to every transaction of the system


It is always possible to secure sensitive transactions.  In the SCT environment, it would take substantial work to limit access for the named above groups due to the nature of their work.  I believe making such an attempt could affect the functionality of the SCT system.  If such a step were made, I would recommend an assessment  by SCT as well as any SCT customers who may have attempted this activity.

Also, a concern with the open records act may also be in play.  Is there anything in the opens records act which would prevent someone from getting these detailed transactions?  If nothing prevents a person from acquiring this data via open records act, then securing the transaction from internal core staff would not make sense.