open it

Under the SSAM guidelines, its expected that third party add-ons that integrate with a DSP will self assess against the following security standards.

Under the ATO's Operational Framework, DSPs are now required to provide the ATO with self assessed information of any and all third party add-ons with more than 1,000 API connections OR API access to a registered tax or BAS agent client list data.

Cloud based DSPs have revised or will be introducing revised self-certification standards for third party add-ons wishing to connect via API to their third party ecosystem that incorporate these new requirements.

For some third party add-ons, this will involve reconfiguring applications to reflect the standards. These changes mean a more consistent approach will be created for third party add-ons to connect to DSPs as the minimum security requirements will be the same across the board. 

Security requirements for add-ons


The aim of these standards is to create a minimum security environment to protect client data and increase the overall security between third party add-ons and DSPs. Find more information about each of the specifications below. 

Security Requirement Security Specifications/Guidelines
Encryption key management Verify that your app meets these requirements for OAuth token management
  • OAuth tokens or customer-identifying information must not be exposed within your app or shared with other parties.
  • Token management once a user completes the OAuth authorisations workflow:
    • OAuth 1.0a
      • Encrypt and store the consumer key, consumer secret, access token and access token secret in persistent memory.
      • Encrypt the access token with a symmetric algorithm (3DES or AES). AES-128 or greater is preferred.
      • Store your AES key in your app, in a separate configuration file.
    • OAuth 2.0
      • Encrypt and store the refresh token in persistent memory. 
      • Encrypt the refresh token with a symmetric algorithm (3DES or AES). AES-128 or greater is preferred.
      • Store your AES key in your app, in a separate configuration file. 
Encryption in transit (MANDATORY) App server is configured using SSL to support only TLS version 1.1 or higher.
(RECOMMENDED) TLS version 1.2 using AES 256 or higher with SHA-256.

Web application endpoints that receive sensitive customer information and/or authentication tokens in URL parameters must not return HTML content via a HTTP Response Body. This is to prevent sensitive customer information from being accidentally leaked to 3rd parties in the subsequent HTTP Referrer request headers. Instead, the web application endpoints should implement a 302 Found redirect. This is particularly important when application end points are handling authentication tokens. 
Authentication Ensure that strong customer authentication is enabled (minimum two step authentication) or single sign on with DSP credentials (minimum two step authentication).
Indirect access to data Third party access to customer data must be clearly stated within application policies and/or terms and conditions, and have a justifiable business need.
Note:
  • Third party access may include access via an external API, or through data that is stored.
  • Justifiable business need may include (but not limited to) the utilisation of third party services, which is functionally required. For example, the use of 3rd party biometric services.
App server configuration Ensure your server's configuration follows industry accepted hardening practice, for example:
Vulnerability management Follow an industry accepted standard for secure code development such as OWASP Top 10 to protect against vulnerabilities such as:
  • Cross Site Request Forgery
  • Cross Site Scripting (including reflected and stored cross site scripting)
  • SQL Injection
  • XML Injection
  • Authentication, Sessions Management and Functional level access control (if any)
  • Forward or Redirectors in use have been validated
  • All app session cookies have the following attributes set: Secure and HTTPOnly
Encryption at rest Encryption at rest using NIST Cryptographic Mechanisms is mandatory for data repositories that hold or manage sensitive commercial or personal information. Examples may include: full-disk, container, application or database level encryption techniques.

We define sensitive commercial or personal information as information which if disclosed could cause harm to the individual or organisation.

Examples include:
  • Personal - date of birth, tax file number, address, income, biometric, credit history etc.
  • Commercial - financial reports, transaction data, bank account information, employee records, trade secrets etc.
Audit logging Audit logging should include both application level (access logs) and event based actions.

You should consider your environment and what logging should be implemented and ensure that the logging records include the following where applicable:
  • Date and time of the event
  • Relevant user or process
  • Event description 
  • Success or failure of the event
  • Event source e.g. application name
  • ICT equipment location and identification

Audit logs must be retained for as long as appropriate to enable future investigation. In most cases logs should be kept for a minimum of one year. Logs must be immutable and secure. 

Data hosting Consideration needs to be given to country, legal, contractual, access, sovereignty and counter-party risks.
Security monitoring practices and breach reporting You need to be able to demonstrate that you scan your environment for threats and that you take appropriate action where you detect anomalies. Monitoring can be at the: network/infrastructure, application or transaction (data) layer.

Where anomalies are detected you must report these to the DSP, providing enough information to enable further monitoring and/or preventative action.


What if the standards are not met?


If a third party add-on does not adequately comply with these specifications, DSPs will issue them with written notice giving them 30 days to advise the treatment plan and up to a further 60 days to complete the required work. 

What are the benefits of these standards?


These standards have been created for the industry, by the industry, with assistance from the ATO and DSPANZ. They increase the minimum level of security across this add-on ecosystem and with a common standard, they improve the portability of third party apps between different DSPs. 

When do the standards come into effect?


The SSAM is expected to apply from:

  • 1 July 2020 for third party add-ons with DSP certified connections currently in place as at 31 December 2019; or
  • 1 January 2020 for all other connections.


Online Forum

Get involved in the discussion! Post your comments and have your say!

Go To Forum

Member Directory

Browse through DSPANZ Members and learn more about them here.

Browse List