Version 1.3

Updated 14 October 2020

Introduction

Purpose

The purpose of this document is to establish standards for all information technology resources within Service Central (Aust) Pty Ltd trading as Eaco Systems. Effective adherence to this policy will ensure the security of information technology resources owned and/or managed by Eaco Systems and its third party vendors, and the successful control of access across all information and systems.

Scope

This policy applies to Eaco Systems’ information technology resources. For the purposes of this policy, information technology resources include information resources (databases, transactional data, attachment data, communication logs and customer data), software resources (including, but not limited to, Eaco Systems’ technology (“the application”)), and physical assets (server infrastructure, including both production and development hosting environments).

Information Security Policy

Hardware Security Standards

Production Servers

All server hardware in a live production environment must:

  • Be hosted in an Australian tier 1 data centre hosting facility.
  • Be physically located in an access controlled, security patrolled environment.

Server Configuration Guidelines

  • Services and applications that will not be used should be disabled where practical.
  • The most recent security patches should be installed on the system as soon as practical, unless application would interfere with business requirements.
  • Root access must not be used where non-privileged account access will suffice.
  • SSH access must only be accessible through private-public key mechanisms with password authentication disabled.
  • Only stable releases of operating systems, services and applications should be installed.
  • PHP applications should always be configured to operate in safe mode with openbasedir set to the minimum required file system access.

Monitoring

  • All systems, including but not limited to Production and Development Servers, network infrastructure, and backup equipment (NAS), must be monitored 24/7.
  • All servers must be monitored for 100% uptime with 24-hour system alerts to be triggered upon detected unscheduled downtime.
  • Standard server monitoring checks must include network connectivity, average processor load, disk usage alerts and server process monitoring.
  • All external systems, including but not limited to DNS providers, gateways, managed firewalls and 3rd party APIs in use by the application must be monitored 24/7 with 24- hour system alerts to be triggered upon detected downtime.
  • All security-related events on critical or sensitive systems must be logged and audit trails saved.
  • All security-related event logging must be kept available for at least 1 month.

Compliance

  • Audits will be performed on a regular basis by authorised Eaco Systems representatives to ensure compliance with this policy.
  • Every effort will be made to ensure that audits do not interfere with everyday operations or cause interruptions of downtime.

Application Security Standards

General

Eaco Systems takes application security seriously. All application features, maintenance and updates should be developed with the following in mind. Wherever possible, Application Security at Eaco Systems should conform with the Open Web Application Security Project (OWASP) Standards (final version 4.0.1).

Development Principles

  • Application Security must be a consideration during all development. “Evil User” stories should be used within our Agile Development framework to analyse potential security threats.
  • The security development paradigms of defence in depth, secure defaults and the principle of least privilege will be applied during all development.

Phishing

  • Eaco Systems will maintain a consistent and clear message to users regarding the type of information they can expect to receive from us (eg never sending them plain text  passwords or requesting account information) to enhance user education about potential phishing behaviour.
  • Eaco Systems will make it easy for users to report any suspicious or fraudulent behaviour, through both forms on our website and through a publicised email address and phone number.
  • In the event of reported or demonstrated fraud or phishing behaviour, Eaco Systems will immediately respond to the situation by removing all access to potentially threatened services and contacting potentially affected users.

XSS (Cross Site Scripting) Prevention

  • All Eaco Systems web-based software must conform to Cross Site Scripting as defined in OWASP current standards:
  • Never Insert Untrusted Data Except in Allowed Locations
  • HTML Escape Before Inserting Untrusted Data into HTML Element Content
  • Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
  • JavaScript Escape Before Inserting Untrusted Data into HTML JavaScript Data Values
  • CSS Escape Before Inserting Untrusted Data into HTML Style Property Values
  • URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
  • Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way
  • Prevent DOM-based XSS

Authentication

  • All non-public data must be restricted by a user login mechanism. All login mechanisms must use Transport Layer Security (TLS).
  • Users should be encouraged to use strong, unique passwords for their accounts.
  • Passwords must never be stored in plain text. Password hashes must not be logged.
  • Sensitive account-related communications should be transmitted by the highest-grade security means practical. For example, password reset message should be attempted to be sent via telephone or SMS rather than by email.

Error Handling, Auditing and Logging

  • Errors or other system-generated notices should never be presented to a publicly-facing interface.
  • Any errors that do occur should be written to a secure error log that is append-only.
  • System administrators will actively monitor all error and debug logs.
  • All significant changes to object state (eg creation of jobs, updating of user details) should be logged against the relevant object to create an audit trail.
  • All error logs must be kept for at least six months.
  • All audit logging must be kept indefinitely.

Information Security

User access to information through the application will be controlled through the use of both coarse-grained user role levels and a fine-grained User Access Control Layer. Where necessary, relationship-dependent access controls should be implemented.

User Roles

  • User Roles constrain at a broad level the types of data and operations a user is able to access.
  • User roles within the core application include: Admin, Internal User Management Team, Service Provider/Supplier, Consumer and Guest.
  • Role based access to information must be carefully considered and implemented with a “need to know” principle.
  • User role based access should be implemented at both the UI level to hide visibility to unauthorised operations / data, as well as the underlying application level to perform system checks on any operation performed.

Access Control Lists

  • Access Control Lists (ACLs) should be used to allow fine-grained control over individual elements of data and operations. Operations and data may be placed into logical groups controlled by a single permission where appropriate.
  • ACLs should be used at both a UI level (to hide visibility to unauthorised operations/ data) and at an underlying application level (to perform system checks on any operation).

Relationship-dependent Access Control

  • When accessing any data, consideration must be given to the perspective of the requesting user, and the relationship between the user and the particular data requested.
  • For example, a user should not be able to edit a provider’s details merely because they are able to edit some providers’ details - they should have an explicit relationship with the provider in question allowing them to edit such details.
security