The Security Model

This section gives a high level overview of the threats that OpenAir is designed to counter and how the individual security features combine to protect your OpenAir data and environment against unauthorized access and use.

Security requirements arise from the need to protect data: first, from accidental loss and corruption, and second, from deliberate unauthorized attempts to access or alter that data. Secondary concerns include protecting against undue delays in accessing or using data, or even against interference to the point of denial of service.

The critical security features that provide these protections are:

Access to OpenAir data, to the OpenAir user interface and add-on services is based on users, roles and permissions, and filter sets.

Users

A user is an individual who has access to an OpenAir account.

  • Generally, most users are employees, but third party consultants, partners, and customers can also be users.

  • Users need to be set up in the OpenAir system through the creation of employee records. For users to have access to OpenAir, their records must include a user ID, and a password, and the user must be marked as active.

  • Users can be granted access to specific applications within the OpenAir user interface as well as specific add-on services.

Roles

A role is a defined access configuration that can be assigned to users — it controls access to functionality, primarily.

  • Each role includes a set of associated permissions that determine the type of data users can see and the tasks they can perform. For example, roles determine whether a user will be able to view and/or create a project or view and/or create a booking.

  • Form permissions can be used to restrict the form data users can view or modify according to their role.

  • A user may only be assigned a single role.

Filter sets

A filter set is a defined access configuration that can be assigned to users — it controls the data set users have access to.

  • Each filter set includes a set of associated permissions that determine the data set users can see. For example, filter sets may determine whether a user will be able to access all projects or only the projects they are booked for or assigned to.

  • A user must be assigned at least one filter set, their primary filter set.

  • A user may be assigned multiple filter sets.

  • Filter set overrides can be set for each of the application the user has access to. This enables to give the user access to a different data set depending on the application they are currently using.

OpenAir Account Access

When a new OpenAir account is deployed, customers must designate at least one employee who will have responsibility for administering the account. The administrator has full privileges to all aspects of OpenAir and usually is the person who sets up account access by assigning roles to users.

  • The first step for setting up account access is to set up roles. See Roles Overview.

    • Two roles are predefined. The Administrator role cannot be modified and grants all access privileges.

    • You can create roles to suit your business requirements. See Typical Custom Roles.

    • OpenAir provides reports for managing roles and other access privileges such as filter sets and approvals. See Privileges Overview.

  • The next step is to set up filter sets. See Filter Sets Overview and Filters Hierarchy Overview.

    • Two filter sets are predefined. The All access filter set cannot be modified and grants access to all data.

    • You can create filter sets to suit your business requirements.

    • You may create hierarchies to group employees, customers and projects under a hierarchical classification tree, e.g. geographical location. You can then create filter sets to grant users access to projects according to the hierarchy.

      See Hierarchy.

  • After roles and filter sets have been set up, users can be given access and assigned roles and filter sets.

    • Create employee records for your users and either:

      • Give them a temporary password and enforce password change on first sign-in.

      • Enable an alternative sign-on method for users to access OpenAir.

      See Configuring and Using Authentication.

    • Remove access to OpenAir if a user is not an active employee. See User Access Removal.

    • Grant the relevant user privileges in the Employee Demographic form. See Application Options Overview.

    • Grant access permission to the relevant OpenAir application and add-on services. See Access Control Overview.

    • Assign users a role and a primary filter set. Set up any filter set overrides for the different module as appropriate. See Filters Hierarchy Overview.

    • OpenAir provides a report enabling you to monitor users' sign-in activity. See User Access Log.

  • You can define form permissions to further restrict what data users can view and/or modify according to their role. See Form Permissions.

  • Consider the security implications and where relevant, grant access selectively to the OpenAir integration and add-on services or to the OpenAir platform tools. See Configuring and Using OpenAir Integrations and Add-on Services and Enabling and Controlling Access to OpenAir Platform Tools.

  • Form scripts could also be used to implement custom rules determining user restrictions and privileges for specific processes and establish segregation of duties. See the User Scripting for information about User Scripting features.

Internal Controls for OpenAir Access

To achieve effective internal controls, you will need a combination of both automated and manual controls that both prevent and detect misstatements or misappropriation of assets. Companies have several responsibilities for establishing good general controls for OpenAir applications.

  • Ensure logical access and application security. Users should have only the information that they need to do their jobs.

  • Segregate duties.

  • Ensure that your organization has user administration controls in place, including:

    • Process for requesting and approving access. If possible, the request, approval, and granting of access should be segregated among different individuals to ensure appropriate application of the process.

    • Access should be reviewed periodically for changes in responsibilities, assurance that terminated employees have had their access revoked, assurance that sensitive/critical access permissions are granted to the appropriate individuals and to them only.

    • Process access termination in a timely manner.

  • Maintain a mapping of role assignment to job function, and map role assignment to job title.

  • Periodically audit the permissions that make up each role to ensure they are appropriate.

  • The administrator role is very powerful, and access to this role should be extremely limited. Ideally your organization should have at least one administrator and one back-up administrator.

  • Audit configuration options, changes to data, record deletions, web services and script deployment logs either periodically or as and when required. See Configuring and Using Auditing features.

  • User scripts could also be used to trigger notifications based on certain criteria or user action. See the User Scripting for information about User Scripting features.