open it

Desktop or server-based products that are primarily under control of the client will typically fall under either Category D or E of the Operational Security Framework (OSF). 

As desktop products are somewhat controlled by clients, the ATO recognises that some controls may not be applicable and that the mandatory requirements apply where DSPs have the control to implement them. Requirements where this may apply are denoted with an asterisk on pages 13 - 14 of the OSF requirements document.

Audit Logging

About the Requirement Evidence Required
DSPs must implement audit logging functionality which enables the traceability of access and actions within software products which can be used to detect anomalies or support the investigation of a security incident.

Logs must be kept for a minimum of 12 months and need to include:
  • Users who logged in and when
  • What a user views in a session
  • Any changes to privileges, permissions and authorisations
DSPs must provide dummy or authentic (with sensitive information redacted) access and event logs which include:
  • Authentication and authorisation
  • Date and time of the event
  • Username / identifier
  • Success or failure of the event
  • Event description
  • ICT equipment location and identification

DSPs can provide an audit log policy to support this requirement.


Authentication

About the Requirement Evidence Required
At a minimum, all solutions must have user-based access, including unique client logins with authentication and authorisation controls implemented e.g. unique username and password. 

  • Shared logins are not permitted and must be blocked
  • Remember me functionality must be limited to less than 24 hours

To strengthen authentication, the ATO recommends implementing Multi-Factor Authentication (MFA) as best practice. More information can be found here

    If MFA is implemented:

    • User description paired with screenshots of MFA workflow
    • User access controls including remember me, session time-out, brute force lockouts
    • Password or access control policy

    DSPs that have not implemented MFA should consider implementing passphrase management, account lockout and resetting passphrase practices as described in the Australian Government - Guidelines for system hardening


    Certification

    About the Requirement Evidence Required
    Category D and E products can self-assess against one of the following standards:

    More information about how each of these certifications and how they apply under the OSF can be found on pages 17 - 20 of the OSF requirements document

      DSPs must provide documentation demonstrating their compliance to one of the approved security standards including comments on why certain controls may or may not be applicable to the organisation and how they apply. 


      Data Hosting

      About the Requirement Evidence Required
      If the product provides any element of data hosting, it must be offshore by default. Offshore hosting arrangements, including redundant systems, are managed by exception only. 

      Where a DSP is storing data outside of Australia, they must:
      • Make it clear to customers that their data is being stored in a foreign jurisdiction
      • Apply the Australian Privacy Principles
      • Provide guidelines to your customers, where your customers use your services to collect and store data about other individuals, on where and how their data is being managed

        Provide details of your hosting provider including:

        • Provider name
        • Provider location (physical address)
        • Redundancy location (physical address)
        • Where the provider is ASD certified or assessed against another security standard

        Any DSP storing data offshore needs to contact the DPO. 


        Encryption Key Management

        About the Requirement Evidence Required
        If the product manages encryption key management and public key infrastructure (PKI), the policy must include asymmetric/public key algorithms, hashing algorithms and symmetric algorithms as per Australian Government - Guidelines for using cryptography. 

            Copy of the key management policy or plan. 


            Encryption at Rest

            About the Requirement Evidence Required
            DSPs should apply encryption at the disk, container, application or database level. Encryption at rest should follow Australian Government - Guidelines for using cryptography. 

                One of the below:

                • Screenshot showing encryption enabled, confirmation of method of encryption applied and algorithm used
                • Licensing agreement or invoice with whitepaper 
                • Policies relating to classification when applying block, field or column encryption

                If encryption at rest is not viable, DSPs should provide a screenshot or policy which demonstrates that all of the below have been met:

                • User/system role-based access controls and active logins and monitoring protocols
                • Restricting or limiting access to database using the principle of least privilege
                • Separation of hosts and segregation of networks or micro segmentation
                • Intrusion prevention and detection controls


                Encryption in Transit

                About the Requirement Evidence Required
                Encryption in transit must use an approved protocol, for example, TLS 1.2 or higher as per Australian Government - guidelines for using cryptography and Annex A of ACSC Implementing Certificates, TLS and HTTPS

                    Indirectly connecting products must provide one of the following:

                    • Licensing agreement with SSP
                    • Screenshots from SSP portal
                    • Screenshot of API call to 3rd party showing TLS protocol

                    Desktop products that directly connect to the ATO are not required to provide evidence for this requirement.


                    Entity Validation

                    About the Requirement Evidence Required
                    Category D DSPs must implement entity validation to ensure consumers/users of a commercial software product are legitimate businesses and have a genuine need to access ATO APIs. DSPs must verify the entity against a reliable and independent source (e.g. the Australian Business Register) and ensure they have valid contact details including a confirmed phone number. 

                    This requirement is optional for Category E DSPs. 

                        DSPs need to provide evidence demonstrating that entity validation is in place as part of the product registration/purchase process.


                        Personnel Security

                        About the Requirement Evidence Required
                        DSPs need to demonstrate that appropriate processes and procedures are in place for hiring, managing and terminating employees and contractors. These may include but are not limited to:
                        • Identity proofing/pre-employment screening
                        • Previous employment checks
                        • Police checks
                        • Employee obligations
                        • Separation activities 

                        Micro DSPs (one or two employees) are exempt from this requirement unless contractors or non-employees have access to source code or data in scope of the OSF. 

                            • Internal policy document detailing how employees maintain confidentiality of enterprise information
                            • Process descriptions detailing pre-employment screening and separate procedures 
                            • Sample contacts detailing conditions of employments


                            Security Monitoring

                            About the Requirement Evidence Required
                            If the product has the ability to relay data to the DSP, security monitoring must be implemented to enable DSPs to scan environmental threats and take action. 
                                • Screenshot of an intrusion detection system such as a firewall that generates alerts
                                • Approach to detect anomalies or a screenshot of a security event and incident management dashboard
                                • Intrusion prevention system which protects end points and scans the DSP environment to prevent malicious events
                                • Policy demonstrating actions that will be taken where anomalies are detected


                                Supply Chain

                                About the Requirement Evidence Required
                                Supply chain visibility seeks to identify entities and their functional roles involved in the transmission of information, operating to and from the system which generates the payload and the ATO. This includes providing details of any third-party connections to your product via APIs. 

                                The functional roles within a supply chain can be defined as:
                                • Data collector 
                                • Data validator
                                • Data integrator
                                • Data analysis and extraction
                                • Data transformer
                                • Data provider 
                                • Data transmitter

                                    DSPs are required to provide the business details of the participants in the supply chain including:

                                    • Entity name
                                    • ABN
                                    • Service provider role or function



                                    Third Party Add-ons

                                    About the Requirement Evidence Required

                                    DSPs that partner with third party add-on providers and allow connection via an API are required to have a security standard in place to govern these add-ons. The security standard for Add-on Marketplaces (SSAM) was developed as a security standard that DSPs could leverage to meet this requirement. More information about the SSAM can be found here.

                                      • Information and details of the security standard in place for add-ons
                                      • List including the third party developers name and a hyperlink to their product




                                      Online Forum

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


                                      Go To Forum



                                      Member Directory

                                      Browse through DPSANZ Members and learn more
                                      about them here.


                                      Browse List