GNM_RCS_Application_Security_TR

Guardian News & Media

GNM RCS

Application security

Technical reference

Prepared by O3 Team Limited

Authors Nigel Robson

Creation date 30/08/2013

Document Ref. GNM_RCS_Application_Security_TR.docx

Version draft for review

• 1. Introduction

     1. Purpose

RCS stores confidential data, primarily personal contact details and financial information, and processes circa £20m of spend annually . Security is therefore very important.

The security model for RCS needs to control the following:

• • Login access to RCS

  • Functional access i.e. who can do what in RCS

  • Data access i.e. who can see what in RCS

  • Expenditure

This document outlines how these requirements are implemented in the RCS application.

• 1. Scope

This document provides an overview of the security model that has been implemented, but does not provide a detailed list of all features that are subject to restricted access.

This document does not provide details of network and host security e.g. how the firewalls are managed and host passwords controlled. These matters are internal to the GNM IT department.

• 1. Access to the application

     1. Intranet only

RCS is only available to users logged into the GNM network. It is not accessible from outside GNM, except through authorised VPN access such as Guardian America and Guardian Australia.

This level of security is managed by the GNM IT department.

• 1. Client specifications

Access to RCS from within GNM is available to PC users and Mac users whose client machines have been configured with valid Operating System version, Browser version, and Java version combinations.

Oracle publishes a Certification Matrix which lists the combinations of client operating system, browser, and java versions that have been tested and shown to work, and which Oracle therefore support.

At the time of writing the matrix for the Oracle 11g Developer software is found at:

http://www.oracle.com/technetwork/developer-tools/forms/oracle-forms-111210certmatrix-1886127.xls

In many cases non-standard configurations will not work and RCS will not be accessible.

GNM regularly uses an unsupported configuration on the Macs, due to a need/desire to upgrade the Editorial Macs’ OS faster than Oracle certifies the newly released versions. All reasonable efforts are made to keep the GNM configuration as close to the certified configuration as possible.

As the rule the PC configurations fit Oracle’s certification matrix.

• 1. Training

Every user is trained in the use of RCS prior to being granted access to the live system.

They are trained on a training system which is a copy of the live system. This allows the user to become familiar with the functions they will be using, and for the trainer to identify and correct any issues.

Training sessions (and re-training sessions) are run by the RCS Administrator.

• 1. Logins & passwords

Logins are defined by the RCS administrator. The RCS administrator receives a request for a new login and then organises and leads the required training. After training has been completed a new login and password is setup for the user.

Users are generally issued with a login matching their network login.

Users are able to choose their initial password, and can change it from within the RCS application whenever they want to, and also when forced to when their password expires.

Password security in RCS adheres to all the requirements of the GNM password policy at the time of writing. Oracle EBS password security was also reviewed and where it was considered to be stronger this extra strength was built into the RCS password security.

The resulting password management criteria implemented are:

• • Passwords must be at least 6 characters long

  • Passwords must contain both alphabetic and numeric characters;

  • Passwords must not contain repeating characters e.g. AA or 11;

  • Passwords cannot be reset to any of the last 12 values used;

  • Passwords cannot be reset to a value used in the last 12 months;

  • Passwords must expire and require resetting every 30 days, or the next time the user logs in thereafter;

  • Users can request a temporary password be sent to their email address if they forget their password;

  • Temporary passwords must be changed the first time they are used;

  • 3 consecutive failures to enter a password correctly shall cause the user account to be locked until the RCS Administrator resolves the matter; and

  • Passwords are stored in encrypted form in the database - the password is passed through the Triple DES (3DES) encryption algorithm before being stored.

• 1. Login sharing

In keeping with GNM policy users are told not the share their login and password with other users.

• 1. Intentional sharing

Historically GNM staff have been prone to sharing logins and passwords.

To remove this temptation, users can have their commissioning responsibility delegated to another user within RCS, if for example they are away on holiday or sick.

NB From time to time the list of current database sessions is monitored to see if a user has multiple concurrent sessions. If this situation is identified the RCS Administrator investigates – it is usually because one session has crashed when a browser was closed, and the user started another.

• 1. Unauthorised usage

To prevent unauthorised login and password usage the GNM password policy and common sense dictate that passwords should not be written down on desks, or put on Postit notes on screens.

• 1. Functional access

     1. Login definition

        1. Business area and Roles

When new users are defined in RCS their login is allocated to one of 3 business areas:

• • Editorial

  • Accounts

  • Sales (used for SLM users)

“Editorial” user logins are then sub categorised into the following roles:

• • Commissioning editor

  • Editorial administrator

  • Department head

  • Managing editor

  • RCS administrator

“Accounts” users are sub categorised between read and write access:

• • Read

  • Write

“Sales” users are sub categorised into these roles:

• • Commissioning editor

  • Editorial administrator

  • Department head

Each of these business area / role combinations map to a database roles, as defined in the MENU_ROLES table. When the login is created it is granted the corresponding database role.

• 1. Spend limits

Editorial users are also allocated spend limits for commissions and other payments they put onto the system. Whenever they overstep their limit the offending commission or payment is queued for financial review.

Typically a new user has a very low self-approve limit, to ensure their spending commitments are closely monitored. These limits can then be raised over time, or lowered, by the Editorial Administrator at the request of the relevant department head.

• 1. Menu access

Access to the menu system is controlled by the database role granted to the user, as described in the previous section. A user’s Business area and Role (and by implication database role) determines which menus, submenus, and menu options he/she sees once logged into RCS. This level of security is a standard feature with Oracle menu Forms.

In a few instances some menu options are programmatically disabled for some users for reasons beyond their business area and role. This is defined within then menu Form itself.

• 1. Screen features

Within many of the screens an additional layer of functional security has been added. This security controls the functions a user can perform in the screen based on their business area and role. In general this is used to control:

• • Which navigation buttons are visible to allow navigation to other screens (effectively replicating the menu access rules);

  • Whether a user can create, update or delete data e.g. only an RCS Administrator can change a contributor’s name.

A library of Boolean functions is used by the code to determine a users’ access level e.g. the library packaged function l_user.editorial_admin returns TRUE if a user is an Editorial Administrator, otherwise it returns FALSE. Calls to this package are commonplace in the main Forms.

• 1. Data access

     1. Access by role

As described in the previous section some data is accessible to all, and some only to specific Business roles.

• 1. Access by cost centre

To avoid burdening users with too much data in the screens, and to ensure they only focus on data relevant to them, users are granted access to a restricted list of Cost centres as defined in the Chart of Accounts. This list is then used to control access to the data.

For example when a user enters a commission onto RCS they must assign it to a Cost centre that they have access to; if it requires approval it will only appear in the queue of an Editorial administrator, Department head, or Managing editor who also has access to that Cost centre.

This principle is applied in all areas of spend managed by the system.

NB The chart of accounts comprises 8 segments, of which the Cost centre is just one. When new logins are created they are allocated a restricted list of codes for each of the 8 segments, but only the Cost centre is used to restrict the expenditure they are able to view.

• 1. Confidentiality

A contributor may wish their name and contact details to be kept confidential i.e. accessible to only the person entering the details and to RCS Administrators.

This is achieved through a “Confidential?” checkbox on the contributor record. Software in all other areas of the system checks this checkbox value, and determines whether or not the data needs to be concealed from the current user.

• 1. Obfuscation of development data

The RCS development and training database are clones of the live database, and consequently contain a copy of the live data.

To further protect data, when it is deemed necessary (e.g. for a demo of the system to an external 3rd party) then the data can be obfuscated. A separate software utility has been written that performs this task. It involves creating the DATA_CONCEALMENT database package and then executing the relevant procedures within it.

This is not done as a matter of course when clones are refreshed as it takes too long to process the large volumes of data.

• 1. Spend control

Key to any security model is an understanding of the “threats” to the system or the business. In the case of procurement system like RCS one significant threat is accidental, uncontrolled, or fraudulent spend. Consequently measures have been put in place to manage this threat.

GNM operates tight budgets for all spend and so all expenditure must be monitored and controlled at all times. Much of this can be done after the fact with standard Oracle EBS reporting. However, RCS implements many measures to facilitate the identification of inappropriate spending upstream at the point of entry, or at least before a commitment is made to make a payment.

Below is a list of measure that have been used to help prevent inappropriate payments:

• • New contributor records have to be approved before any payment can be instructed;

  • All expenditure over a users’ limits must be approved by a more senior user;

  • User spend limits can be changed at any time on an individual basis, up or down;

  • Payments over £5,000 must be approved by the Editor’s office;

  • All commissions require approval if the contributor is on contract;

  • All commissions require approval if the contributor is on staff;

  • All foreign currency commissions require approval;

  • Exchange rates are kept up to date by synchronising them with Oracle EBS;

  • An approver can raise a “problem” against an item of expenditure, and that problem can be referred back to the original user. This ensures users see and correct their own errors;

  • All commissions are reviewed by the Rights team, at which point rights and fees are monitored;

  • Reports are available to highlight commissions approved by (a) Department heads and (b) Managing editors;

  • Only RCS administrators can change a contributor’s name;

  • Duplicate contributors are proactively identified and queued for review, based on any repetition of name, address, postcode, phone number, email, or VAT details;

  • Duplicate payments are identified based on the combination of contributor/payee, date and fee;

  • Standard rates for lineage and for printed area mean users can be presented with the appropriate fee for a contribution rather than determine it themselves;

  • No payments are made to potential duplicate contributors until the matter has been resolved by the RCS Administrator;

  • A change history is kept of changes to contributor contact details;

  • A change history is also kept of changes to key commission data;

  • A change history is also kept of changes to key contract data;

  • A change history is also kept of changes to key expense claim data;

  • The creation and renewal of contracts has been centralised to the Rights department and the Managing editors office;

  • As much published content as possible is automatically processed within RCS to ensure no unnecessary payments are made for staff content, duplicated content, republished content, and content supplied under subscription.

End of Document