UNCLASSIFIED
November 2018
Operational Framework for Digital Service Providers
Draft Requirements and Implementation Approach
/ For more information on this position paper, email

Contents

Requirements Summary 3

Overview 5

Operational Framework for Digital Service Providers Approval Process 6

Certification and Assessment 7

Encryption 9

Data in Transit 9

Data at Rest 9

Payload 9

Supply Chain Visibility 11

Onshore/Offshore Data Hosting 12

Identity and Authentication 14

Miscellaneous 15

Audit Logging 15

Software Identifier in message 15

Requirements Summary

/ Requirement / Applicable to / Timeframe
Certification
1 / Independent assessment performed by a qualified, registered assessor in line with iRAP or ISO / IEC 27001 / Digital Service Provider (DSP) product/service has:
-  Large/high leverage user base, AND
-  DSP service is running in the cloud / Commence process by 01 February 2018.
2 / Self-assessment performed by a relevant internal representative in line with ISO / IEC 27001 / DSP product/service has:
-  DSP service is running in the cloud, AND
-  DSP is consuming medium and/or high risk APIs / Commence process by 01 February 2018.
3 / Self-assessment performed by a relevant internal representative in line with ISO / IEC 27001, ASVS3.0 or SOC2. / All other DSP products/services / Commence process by 01 February 2018.
Encryption
4 / Implement encryption of data in transit for all transmissions over public or shared network infrastructure using ASD approved cryptographic algorithms and protocols / All DSPs / 01 February 2018
5 / Implement full-disk, container, application or database level encryption techniques using ASD approved cryptographic algorithms and protocols. / All DSPs that have control over a customer’s data at rest / 01 February 2018
6 / Implement payload encryption using Cryptographic Message Syntax and an ASD approved cryptographic algorithm / DSPs that do not adopt Supply Chain Visibility requirements / TBD
Supply Chain Visibility
7 / Implement supply chain visibility solution / DSPs that do not adopt payload encryption / TBD
Onshore/Offshore Data Hosting
8 / Consistent with guidelines for APRA-regulated entities the ATO expects DSPs to apply a cautious and measured approach when considering retaining data outside the jurisdiction it pertains to. By default, the ATO expects DSPs to store data onshore. / All DSPs / Immediate
9 / Where there is a compelling reason for storing data outside of Australia a DSP must consult with the ATO prior to entering into any offshore data hosting arrangement so that the ATO may satisfy itself that the impact has been adequately addressed. As part of the consultation:
a. Digital Service Providers must demonstrate that they have considered the jurisdictional risks of storing data in a foreign jurisdiction.
b. The ATO can provide advice on jurisdictional constraints. / All DSPs / Immediate – DSPs who don’t store data onshore currently must commence consultation with the ATO by 01 February 2018
Identity and Authentication
10 / DSPs must either:
• use the current Cloud Authentication and Authorisation (CAA) solution with the addition of a multi-factor credential, or
• consume the government provided TDIF credential, or
• become a TDIF credential provider in their own right and consume their own credential. / All DSPs / TBD – After TDIF becomes available
11 / Review security credential risks and develop a plan to manage the risks identified / All DSPs / 31 March 2018
12 / Implement a multifactor credential solution or provide assurance of sufficient controls in place by. / All DSPs providing cloud products and services / 31 March 2018
Miscellaneous
13 / Implement appropriate Audit Logging capabilities / All DSPs / 01 July 2018
14 / The Product ID of the software that produces the payload information must be included in the message / All DSPs / Immediate

Overview

The following diagram provides a graphical overview of the relevant controls applicable to different products and services provided by DSPs.

Operational Framework for Digital Service Providers Approval Process

The requirements and timeframes outlined within this document are expected to be met by all DSPs expecting approval under the DSP Operational Framework.

The approval process involves a DSP completing a Questionnaire and providing relevant evidence. Once all the relevant information has been provided the ATO will assess the evidence provided and either:

·  Grant approval

·  Grant conditional approval

·  Request further information

·  Reject the application.

Conditional Approval

Conditional approval may be granted in situations where the DSP is undertaking necessary steps to meet the DSP Operational Framework requirements but do not yet meet those requirements (eg undertaking certification against ISO 27001). A review date will be set when conditional approval is granted.

Staged Approval Process

The process of being approved under the DSP Operational Framework will be done in stages based on the following principles:

  1. All new DSPs will need to seek approval under the DSP Operational Framework before consuming an API or web service.
  2. All DSPs wishing to consume value-added services will be expected to commence the approval process by 01 February 2018.
  3. All DSPs consuming PLS services will be expected to commence the approval process by 01 March 2018.
  4. All DSPs consuming Single Touch Payroll services will be expected to commence the approval process by 01 April 2018.
  5. All DSPs consuming taxation related services will be expected to commence the approval process by 01 May 2018.
  6. All DSPs consuming Superannuation related services will be expected to commence the approval process by 01 June 2018.

This staged approach is necessary given the workload involved in assessing the evidence provided by each DSP.

Certification and Assessment

Various Cyber Security Standards exist to help organisations and IT professionals identify and mitigate cyber security risks. Certification against a recognised standard is a key component in appropriately addressing the risks of operating within the broader digital ecosystem.

Certification Options

The following certification standards have been assessed:

·  iRAP

·  ISO/IEC 27001

·  OWASP ASVS3.0

·  SOC2

Other standards may be considered on a case-by-case basis.

The DSP Operational Framework adopts a tiered approach to certification requirements for DSPs.

Key Definitions

-  Individual taxpayer or superannuation related information means information that has been stored for the purpose of a taxation or superannuation law and identifies, or is reasonably capable of being used to identify an individual.

-  Accessible means an end user has the ability to view the information readily.

-  Large/high leverage user base means:

o  a DSP product or service that stores over 10,000 ‘accessible individual taxpayer or superannuation related information’ records. Records that relate to the same individual are only counted once.

o  Any gateway or sending service provider.

-  DSP service is running in the cloud means:

o  a software-as-a-service offering provided direct to end users, or

o  a software-as-a-service offering to another DSP to consume as part of a supply chain.

-  Direct to ATO, product hosted on customer’s premise or on customer’s IaaS/PaaS Cloud means software that is loaded and stored on a client’s local computer, service (IaaS/PaaS) and/or device and transmits direct to the ATO.

-  Indirect to ATO, product hosted on customer’s premise or on customer’s IaaS/PaaS Cloud via gateway means software that is loaded and stored on a client’s local computer, service (IaaS/PaaS) and/or device and uses a gateway or sending service provider to facilitate the transmission of a message to the ATO.

Requirements

  1. A DSPs certification requirements will fall into one of the following categories:

DSP’s product/service characteristics / Requirement
o  Large/high leverage user base, AND
o  DSP service is running in the cloud / Independent assessment performed by a qualified, registered assessor in line with iRAP or ISO / IEC 27001
o  DSP service is running in the cloud, AND
o  DSP is consuming medium and/or high risk APIs / Self-assessment performed by a relevant internal representative in line with ISO / IEC 27001
o  All other DSP products/services / Self-assessment performed by a relevant internal representative in line with ISO / IEC 27001, ASVS3.0 or SOC2.

Implementation Timeline

It is recognised that the certification process can take time depending on the standard chosen and the maturity of the organisation. The ATO expects most DSPs will be able to complete the process in 3-6 months however longer timeframes will be required for some. The ATO will work with DSPs on an individual basis to determine an appropriate timeframe. The ATO expects DSPs to commence the process by 01 February 2018.

Access to new services while a DSP is progressing through the certification process will be assessed on a case-by-case basis. However, evidence of commitment to undergo certification and satisfactory responses to the security questionnaire will form the basis for this assessment.

Encryption

Data in Transit

Encryption of data in transit can be used to provide protection for sensitive or classified information being communicated over public network infrastructure.[1]

Requirement

  1. All DSPs must implement encryption of data in transit for all transmissions over public or shared network infrastructure using ASD approved cryptographic algorithms and protocols.

Implementation Timeframe

DSPs will be required to implement this change by 01 February 2018. Where DSPs are not able to meet this timeframe they must consult with the ATO.

Data at Rest

Encryption of data at rest can be used to reduce the physical storage and handling requirements for media or systems containing sensitive or classified information to an unclassified level.[2]

Requirement

  1. DSPs that have control over a customer’s data at rest must implement full-disk, container, application or database level encryption techniques using ASD approved cryptographic algorithms and protocols.

Implementation Timeframe

DSPs will be required to implement this change by 01 February 2018. Where DSPs are not able to meet this timeframe they must consult with the ATO.

Payload

Payload encryption can be used to provide end-to-end protection for sensitive or classified information. Payload encryption is the preferred solution for transporting sensitive or classified information through a supply chain. An alternative to using payload encryption is detailed under Supply Chain Visibility.

Requirement

  1. DSPs that don’t adopt Supply Chain Visibility requirements must implement payload encryption using Cryptographic Message Syntax and an ASD approved cryptographic algorithm.

Implementation Timeframe

Implementing this change requires significant design, development and consultation efforts across industry. Timelines for this work are yet to be finalised.

Supply Chain Visibility

When information is sent from one party to another (eg from a taxpayer to the ATO), the data can be sent through a number of different parties in a ‘supply chain’. Each party in the supply chain can perform one or more functional roles. The most basic supply chain involves only 2 parties.

The below design principles and functional roles will inform the development of a future technology solution to deliver supply chain visibility. This future technology solution is not currently planned and will not be available in the short term. An interim solution will be developed to cater for Sending Service Providers under Single Touch Payroll.

Supply Chain Visibility involves annotating the identity and functional role to the message for every DSP that reads or modifies the data – where the payload is not encrypted end-to-end (ie payload-level encryption).

Where payload encryption has been implemented supply chain visibility is not required.

Design Principles

  1. The technical solution will seek to balance the need for risk mitigation against need for operational effectiveness.
  2. If a DSP reads or modifies any data, the message must be annotated with that DSP’s identity and functional role(s) in the supply chain.
  3. DSPs are not responsible for information after it has been securely delivered to an authenticated and authorised customer.
  4. If a DSP routes a message, the message must be annotated with that DSP’s Identity and functional role for operational support reasons.

Functional Roles within a Supply Chain

The functional roles within a supply chain were defined as:

·  Data Collection - Party responsible for the acquisition of data through user interface interaction or APIs.

·  Data Validation – Party responsible for the verification of data types, structures, formats and/or data values.

·  Data Integrator – Party responsible for combining data from multiple sources for use.

·  Data Analysis & Extraction – Party responsible for performing analysis on data to extract a data sub-set or additional derived/calculated data.

·  Data Transformation - Party responsible for change syntactic representation of data.

·  Data Provider - Party responsible for the payload (which maybe encrypted).

·  Data Transmitter - Party responsible for the message with the payload. (eg. ebMS3/AS4 transmission).

Requirement

  1. All DSPs that do not adopt payload encryption must implement supply chain visibility.

Onshore/Offshore Data Hosting

Storing data in a foreign jurisdiction presents additional risks that must be considered.

Requirements

  1. Consistent with guidelines for APRA-regulated entities the ATO expects DSPs to apply a cautious and measured approach when considering retaining data outside the jurisdiction it pertains to. By default, the ATO expects DSPs to store data onshore.
  2. Where there is a compelling reason for storing data outside of Australia a DSP must consult with the ATO prior to entering into any offshore data hosting arrangement so that the ATO may satisfy itself that the impact has been adequately addressed. As part of the consultation:
  3. DSPs must demonstrate they have considered the jurisdictional risks of storing data in a foreign jurisdiction.
  4. The ATO can provide advice on jurisdictional constraints.

Implementation Timelines

All new DSPs must meet the data hosting requirements.

Existing DSPs who store data outside of Australia must notify the ATO and provide evidence of how they meet the requirements and principles by 1 February 2018

Where a DSP is unable to meet the requirements and/or principles the DSP will be expected to transition data to Australia within a reasonable timeframe.

Additional conditions for offshore data hosting

  1. Consistent with APRA’s Cross Industry Prudential Practice Guide CPG 235, the ATO expect the following would normally be applied to the assessment and ongoing management of offshore data hosting:

• enterprise frameworks such as security, project management, system development, outsourcing/offshoring management and risk management,