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
|
| 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:
|
| 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:
|
| 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:
|
| 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:
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.