purpose - australian taxation office · web viewthe intent of this questionnaire is to develop a...

Digital Service Provider Operational Framework

Security QuestionnaireOctober 2019 V1.4

UNCLASSIFIEDEXTERNAL

Contents

Purpose 3

How to complete this questionnaire 3

Minimum evidence requirements 3

What’s next? 4

Digital Service Provider Lifecycle Overview 4

Questions 4

Requirements for products and / or services controlled by the client 5

Requirements for products and /or services controlled by the DSP 7

Section A – About you as a Digital Service Provider 10

Section B – Requirements for products and /or services controlled by the client 12

Section C - Requirement for products and/or services controlled by the DSP 19

Section D – Sending Service Providers (SSP) only 28

Section E – DSPs with an add-on marketplace only 29

Submitting your questionnaire 30

Operational Framework Terms and Conditions 30

Document Details 31

Version History 31

UNCLASSIFIED EXTERNAL 2

Purpose The intent of this questionnaire is to develop a base level of understanding of the security posture of a Digital Service Provider (DSP), their products and supply chain arrangements.

The Operational Framework aims to strengthen the security of the digital taxation and superannuation ecosystem. By establishing a level of confidence and certainty, the ATO will be able to continue to invest in and extend the services made available through our digital wholesale channels.

This document is best read in conjunction with the DSP Operational Framework – Requirements to utilise ATO digital services .

How to complete this questionnaire

Minimum evidence requirements Please read in conjunction with DSP Operational Framework – Requirements to

utilise ATO digital services. Where you have answered ‘yes’ to a question, evidence must be provided in line with

the requirement. Transitional requirements apply to Super DSPs as per the Super Transition Plan You can submit the questionnaire to us through our Online services for DSPs or

[email protected]. Evidence can be embedded directly into the questionnaire, or separately as an

appendix document or combined into a .zip file and submitted with your questionnaire. Clearly reference your attached evidence documentation, aligning to the questionnaire sections.

If you want to securely send your completed evidence to the ATO, the ATO can provide a secure channel facility to transfer your data upon request.

Responses to this questionnaire need to be true and correct to the best of your knowledge. Providing false or misleading information in this questionnaire could lead to your software product or service being de-whitelisted.

You will need to complete one questionnaire per product.


Please complete the relevant sections of this questionnaire depending on your operating model.

Section A - About you as a Digital Service Provider to be completed by all DSPs Section B – If you are providing products and /or services controlled by the client Section C – If you are providing products and /or services controlled by the DSP Section D – If you are operating as a Sending Service Provider (SSP) in addition to

Section C Section E – If you have an add-on marketplace in addition to Section B or Section C

https://softwaredevelopers.ato.gov.au/OnlineservicesforDSPs

https://softwaredevelopers.ato.gov.au/TransitioningexistingSuperannuationProviders

https://softwaredevelopers.ato.gov.au/sites/default/files/resource-attachments/DSP_Operational_Framework_Requirements_to_utilise_ATO_digital_services.docx




What’s next?Whilst completing this questionnaire, please ensure you have registered for Standard Business Reporting (SBR). You can complete your conformance suite testing in the External Vendor Testing Environment (EVTE) in parallel to the Operational Framework.

Once you have received conditional or full approval for the Operational Framework and completed EVTE you can enter Product Verification Testing (PVT). To initiate the PVT process you can either raise a ‘Request to Execute PVT’ ticket on the Online services for DSPs complete the SBR ‘Certify a service’ form.

After successful completion of PVT your product will be certified and commercial software products will be listed on the SBR Product Register.

If you have developed a commercial STP product you can also request to be listed on the STP Product Register.

Digital Service Provider Lifecycle OverviewThe below diagram illustrates a high level overview of the key stages for a DSP.

QuestionsIf you need assistance in completing this questionnaire please contact the Digital Partnership Office at any time through either Online services for DSPs or [email protected]


mailto:[email protected]


https://softwaredevelopers.ato.gov.au/STPregister

http://www.sbr.gov.au/products-register/sbr-product-register-full-list

http://www.sbr.gov.au/software-developers/what-can-i-expect/certification-form



http://www.sbr.gov.au/software-developers/what-can-i-expect/registration-form


Requirements for products and / or services controlled by the client

Requirements Connects directly tothe ATO

Connects indirectly to the ATO

(e.g. via gateway or SSP)

Personnel Security (Mandatory) You need to demonstrate that appropriate processes and procedures are in place for hiring, managing and terminating employees and contractors.

Encryption in Transit (Mandatory) Encryption in transit is enforced using an approved cryptographic protocol (for example, TLS 1.3) and algorithm as per the Australian Government - Guidelines for using cryptography (May 2019).

Encryption at Rest (Optional)

Payload Encryption Not applicable Payload encryption solution is not currently available, but will be developed in the near future.

Encryption Key Management

(Mandatory) Encryption key management (including public key infrastructure (PKI)) complies with Australian Government ISM .

The scope of the policy where suitable should cover three categories:

Asymmetric/public key algorithms Hashing algorithms Symmetric algorithms

Audit Logging (Mandatory) Appropriate audit logging functionality is implemented by your software product to enable traceability of user access and actions.

Product ID in Message Header

(Mandatory) DSPs with multiple products will need one product ID per product.

The Product ID of the software that produces the payload information must be included in the message.

This requirement does not apply to SuperStream messages or


https://www.cyber.gov.au/ism

https://www.cyber.gov.au/sites/default/files/2019-05/22.%20ISM%20-%20Guidelines%20for%20Using%20Cryptography%20(MAY19).pdf


sending service providers.

Self-Certification (Mandatory) Self-Certification against either:

iRAP ISO / IEC 27001 SOC2 or OWASP ASVS 3.0 or latest version

Supply Chain Visibility

Not applicable (Mandatory) The supply chain visibility solution is being developed in the near future. Until then interim measures are in place.

Data Hosting Not applicable

Multi-factor Authentication

(Optional) The ATO recommends that multi-factor authentication (MFA) is applied, or the option is made available where practical to do so.

DSPs that have not implemented MFA, should consider implementing passphrase management, account lockout and resetting passphrase practices described in Australian Government - Guidelines for system hardening (April 2019).

Security Monitoring Practices

(Mandatory) DSPs that utilise web services (e.g. hybrid desktop environments) and are consuming medium and high risk APIs are required to have security monitoring in place.

For example:

Network / infrastructure layer Application layer Transaction (data) layer

DSP with an add-on marketplace

(Mandatory) DSPs that allow 3rd party add-ons to connect to their software via an API should have security controls in place to govern access.

If you are a DSP with an add-on marketplace you will need to provide us with additional information.


https://www.cyber.gov.au/sites/default/files/2019-04/15.%20ISM%20-%20Guidelines%20for%20System%20Hardening%20(APR19).pdf


Requirements for products and /or services controlled by the DSPThis includes Software as a Service (SaaS), gateways and sending service providers

Requirements Low volumes of taxpayer or superannuation records (<10k)

Highly leveraged or high volumes of

taxpayer or superannuation records (>10k)

Consumes no / low risk APIs only

Consumes medium or high risk APIs

-

Personnel Security (Mandatory) You need to demonstrate that appropriate processes and procedures are in place for hiring, managing and terminating employees and contractors.

Encryption in Transit

(Mandatory) Encryption in transit is enforced using an approved cryptographic protocol (for example, TLS 1.3) and algorithm as per the Australian Government - Guidelines for using cryptography (May 2019).

Encryption at Rest (Mandatory) Encryption at rest is mandatory for data repositories that hold or manage tax or superannuation related information.

Encryption of data at rest is enforced using an approved algorithm (for example, AES-256) as per Australian Government - Guidelines for using cryptography (May 2019).

Examples may include; full-disk, container, application or database level encryption techniques.

Payload Encryption Payload encryption solution is not currently available, but will be developed in the near future.

Encryption Key Management

(Mandatory) Encryption key management (including public key infrastructure (PKI)) complies with Australian Government ISM .

The scope of the policy where suitable should cover three categories:

Asymmetric/public key algorithms Hashing algorithms






Symmetric algorithms

Audit Logging (Mandatory) Appropriate audit logging functionality is implemented by your software product to enable traceability of user access and actions.

Product ID in Message Header

(Mandatory) DSPs with multiple products will need one product ID per product.


This requirement does not apply to SuperStream messages or sending service providers.

Self-Certification or Independent Certification

(Mandatory) Self-Certification against either: iRAP ISO / IEC 27001 SOC2 or OWASP ASVS

3.0 or latest version

(Mandatory) Self-Certification against either: iRAP or ISO / IEC 27001

(Mandatory) Independent Certification against either: iRAP or ISO / IEC 27001

Supply Chain Visibility (Mandatory) The supply chain visibility solution is being developed in

the near future. Until then, interim measures are in place.

Data Hosting (Mandatory) Data hosting on shore by default. Offshore hosting arrangements (including redundant systems) are managed by exception only.

Multi- factor Authentication

End users accessing the product or service(Mandatory) Multifactor authentication (MFA) is mandatory for end users that can access taxation or superannuation related information of other entities or individuals (e.g. tax agents, employers)

(Optional but recommended) MFA is optional but recommended for end users that only have access their own information and do not have access to taxation or superannuation related information of other entities or individuals. (e.g. employees accessing employee portals)

DSP Staff (including contracted labour) access the product or service(Mandatory) MFA is mandatory for DSP staff with access to taxation or superannuation related information. This position applies unless the DSP can adequately demonstrate that the internal user does not perform a privileged administration role (system / database level) and the full range of compensating controls specified within the


Australian Government ISM have been suitably implemented.

(Optional but recommended) MFA is optional but recommended for DSP staff (other than privileged users) without access to taxation or superannuation related information of other entities.

NoteTokens or temporary credential should be isolated to an individual device and expire once used. Any token or temporary credential should expire within 24 hours.

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

Security Monitoring Practices

Not applicable (Mandatory) Security monitoring is in place.

For example:

Network / infrastructure layer Application layer Transaction (data) layer

Sending Service Provider (Mandatory for Sending Service Providers only)

Sending Service Providers need to provide the following information:

Intended business model (ie will the service be offered to market)

Functional role(s) performed within the supply chain Services that will be offered (eg file upload, portal, REST API

etc) Architecture of the service, including services that are hosted

on shared infrastructure

DSP with an add-on marketplace

(Mandatory) DSPs that allow 3rd party add-ons to connect to their software via an API should have security controls in place to govern access.

If you are a DSP with an add-on marketplace you will need to provide us with additional information.

Note: sending service providers/gateways are excluded from this definition.





Section A – About you as a Digital Service Provider

Date of questionnaire completion

Do you have an AUSkey? ☐Yes ☐No

Registered ABN

Entity Legal/Trading Name

Registered address

Product Name

Link to Website

Contact Name

Contact Email

Contact Phone Number

Are you registered for SBR? ☐Yes ☐No – Follow the link to register for SBR

What forms/services are you developing? Check the appropriate model from the following list or specify below if not listed:

☐Tax Practitioner Services (including IITR, CUREL etc.)

☐Payroll Services (including PAYEVNT, TFND etc.)

☐Superannuation Services (including STIC, MAAS, MATS etc.)

☐Other SBR Services (please specify)

What is the risk rating of the services to be consumed?

Check the appropriate risk rating from the following list:

☐1-no risk ☐2-low risk ☐3-med risk ☐4-high risk

Are you expecting your product/service to interact with 10,000 or more TFN or Superannuation records?

☐Yes

☐No

☐Unsure


https://softwaredevelopers.ato.gov.au/APIriskratings



What is your DSP operating model / supply chain and API consumption?

Provide a supporting taxonomy diagram demonstrating your supply chain and API consumption to and from the ATO including any cloud and hosting interactions.

Example:

Check all of the statements applicable to your product from the following list:

☐Operates as a desktop product

☐Operates as a cloud product

☐The product connects directly to the ATO

☐ The product connects to the ATO via a sending service provider or gateway

☐ The product is controlled by the client

☐ The product is controlled by the DSP

☐The product provides a gateway or sending service provider solution to a client

Attach taxonomy diagram below:

Do you have an add-on marketplace which allows 3rd party products or services to connect to your software via an API (application programming interface)?

☐Yes ☐No


Continue to Section B of the questionnaire if you are providing products and /or services controlled by the client

Continue to Section C of the questionnaire if you are providing products and /or services controlled by the DSP

Continue to Section D of the questionnaire in addition to Section C if you are operating as a Sending Service Provider (SSP)

Continue to Section E of the questionnaire in addition to Section B or Section C if you have an add-on marketplace

Section B – Requirements for products and /or services controlled by the client

B1 - (MANDATORY) Personnel Security

This requirement seeks to mitigate threats from malicious internal actors (trusted insiders).

You need to demonstrate that appropriate processes and procedures are in place for hiring, managing and terminating employees and contractors.

It is expected that security measures need to be in place for all DSPs.

Note: Micro DSPs (one or two employees) are exempt from this requirement unless contractors or non-employees have access to source code or taxation or superannuation related information.

Examples of suitable evidence

Internal policy document detailing how employees maintain confidentiality of enterprise information.

Process descriptions detailing pre-employment screening and separation procedures.

Sample contracts detailing conditions of employment.

Micro DSPs

Will be required to confirm that no contractors or non-employees have access to the source code.

If they do personnel security provisions will apply

☐Yes

☐No

[Your response here with suitable evidence attached]

B2 - (MANDATORY) Encryption in Transit

This requirement seeks to protect the confidentiality and integrity of taxation and superannuation related information in transit.

You will need to provide evidence that you use an approved cryptographic protocol (for example, TLS 1.3) and algorithm to encrypt data in transit as per Australian Government - Guidelines for using cryptography (May 2019).


When directly connecting to the ATO provide a screenshot of one of the below:

SSL certificates Showing HTTPS protocol

being enforced Call to API TLS handshake protocol

being enforced.

When using a SSP/Gateway to indirectly connect to the ATO provide a screenshot of one of the below:

Licensing agreement or

☐Yes

☐No




contract for service with SSP Call to the SSP REST API Screenshots from within SSP

portal configuration page showing DSP as a linked entity

Handshake agreement with SSP showing TLS 1.2 or HTTPS being enforced


B3 - (OPTIONAL) Encryption at Rest

This requirement seeks to protect taxation or superannuation related information from unauthorised access.

Encrypting data at rest can be full-disk, container, and application or database level encryption techniques.

Approved algorithms to encrypt data at rest are as per Guidelines for using Cryptography (May 2019)


Screenshot showing encryption enabled at the database or disk level with the type of encryption at rest being used

When using ‘out of the box’ encryption a licensing agreement or screenshot showing ‘out of the box’ encryption at rest enabled

If using the infrastructure of a cloud provider to encrypt data at rest, an invoice or contract agreement could be provided or screenshot from within the cloud environment showing encryption enabled

☐Yes

☐No


B4 - Payload Encryption – TBA Examples of suitable evidence

TBA

☐Yes

☐No





B5 - (MANDATORY) Encryption Key Management

This requirement seeks to minimise the risks of compromised encryption keys.

You need to demonstrate that a policy or process in place to govern the use of your encryption keys in line with the Australian Government ISM.

The scope of this policy should cover three categories:

asymmetric/public key algorithms hashing algorithms symmetric algorithms


An internal policy document which covers the scope of encryption key management.

This document should include details relating to:

generation distribution storage access renewal revocation rotation archiving length and complexity of keys destruction of compromised

keys recovery

☐Yes

☐No


B6 - (MANDATORY) Audit Logging

This requirement seeks to ensure traceability of access and actions.

Audit logging should include both application level (access logs) and event based actions.

Consider your environment and what logging should be implemented and 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


Sample of a dummy access and event audit log

A data dictionary that describes the data attributes and maps against key audit log components

☐Yes

☐No



name ICT equipment location and

identification Data identifiers (product ID, Tax

File Number (TFN)).


B7 - (MANDATORY) Product ID in Message Header

DSPs with multiple products will need one product ID per product.


This requirement does not apply to SuperStream messages or Sending Service Providers.


Screen shot of the product ID in the message header

☐Yes

☐No


B8 - (MANDATORY) Self- Certification:

The self-certification requirement seeks to provide the ATO with a level of assurance that you have robust security practices in place across your organisation and software product.

This is done by way of self-certification against one of the below standards:

iRAP ISO/IEC 27001 SOC2 OWASP ASVS 3.0 or latest

version

The scope of self-certification should


Completed documentation demonstrating your conformance with the requirements (full control suite) of one of the approved security standards outlined above.

☐Yes

☐No

☐In progress


cover relevant organisational policies, procedures and data repositories that hold or manage tax or superannuation related information.


B9 - Supply Chain Visibility (payload encryption)

The supply chain visibility requirement seeks to identify the entities and annotate their functional roles involved in the transmission of information from the system which generates the payload through to the ATO.

The functional roles within a supply chain are defined as:

Data Collector: Party responsible for the acquisition of data through user interface interaction or APIs

Data Validator: 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 and Extraction: Party responsible for performing analysis on data to extract a data sub-set or additional derived/calculated data

Data Transformer: Party responsible for change syntactic representation of data

Data Provider: Party responsible for the payload (which may be encrypted)

Data Transmitter: Party responsible for the message with the payload. (e.g. ebMS3/AS4 transmission).

Examples of suitable evidence=

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

Entity name ABN Service provider role or

function within the supply chain

The supply chain visibility solution is being developed in the near future. Until then, interim measures are in place.

☐Yes

☐No



B10 - (OPTIONAL) Multi-Factor Authentication

This requirement seeks to minimise the opportunity for unauthorised users to access taxation or superannuation related information.


User manual, user description or instruction paired with screen shots of the user interface

☐Yes

☐No

☐In progress


B11 - (MANDATORY for hybrid/web based models) Security Monitoring Practices

This requirement seeks to detect and respond to cyber-attacks, channel misuse and business threats.


Network / Infrastructure layer – relevant combinations of the below:

Screen shots (product page, the management console page)

Product purchase/ownership doco (e.g. receipts, front page of a contract of product/support/service)

Configuration files Photos of the product Photos of SOC/SIEM centre

(using the products)

Application layer – relevant combinations of the below:

Screen shots of the function page in the application

Reports from the backend system

Transaction (data) layer – relevant combinations of the below: Reports from the backend

system Previous unusual cases

☐Yes

☐No


Section C - Requirement for products and/or services controlled by the DSPC1 - (MANDATORY) Personnel Security

This requirement seeks to mitigate


Internal policy document

☐Yes

☐No


threats from malicious internal actors (trusted insiders).

You need to demonstrate that appropriate processes and procedures are in place for hiring, managing and terminating employees and contractors.

It is expected that security measures need to be in place for all DSPs.

Note: Micro DSPs (one or two employees) are exempt from this requirement unless contractors or non-employees have access to source code or taxation or superannuation related information.

detailing how employees maintain confidentiality of enterprise information

Process descriptions detailing pre-employment screening and separation procedures or

Sample contracts detailing conditions of employment

Micro DSPs

Will be required to confirm that no contractors or non-employees have access to the source code.

If they do Personnel Security provisions will apply.


C2 - (MANDATORY) Encryption in Transit

This requirement seeks to protect the confidentiality and integrity of taxation or superannuation related information in transit.

You will need to provide evidence you use an approved cryptographic protocol (for example, TLS 1.3) and algorithm to encrypt data in transit as per Guidelines for using Cryptography (May 2019) .


When directly connecting to the ATO provide a screenshot of one of the below:

SSL certificates Showing HTTPS protocol

being enforced Call to API TLS handshake protocol

being enforced.

When using an SSP/Gateway to indirectly connect to the ATO provide a screenshot of one of the below:

Licensing agreement or contract for service with SSP

Call to the SSP REST API Handshake agreement with

SSP showing TLS 1.2 or HTTPS being enforced

Screenshots from within SSP portal configuration page showing DSP as a

☐Yes

☐No




linked entity.


C3 - (MANDATORY) Encryption at Rest

This requirement seeks to protect taxation or superannuation related information from unauthorised access.

The scope of encryption at rest covers data repositories that hold or manage tax or superannuation related information.

You will need to provide evidence that you use an Approved algorithm (for example, AES-256) to encrypt data at rest are as per Guidelines for using Cryptography (May 2019).

Encrypting data at rest can be full-disk, container, and application or database level encryption techniques.


Screenshot showing encryption enabled at the database or disk level with the type of encryption at rest being used

When using ‘out of the box’ encryption a licensing agreement or screenshot showing ‘out of the box’ encryption at rest enabled

If using the infrastructure of a cloud provider to encrypt data at rest, an invoice or contract agreement could be provided or screenshot from within the cloud environment showing encryption enabled.

Where encryption at rest is not viable, evidence must be provided of a full range of data protection controls.

These include: User/system (service

account) access control (including authentication and authorisation) and active logging and monitoring protocols

Intrusion Detection System/Intrusion Prevention System

Internal employee screening or vetting

Isolation of/and handling procedures for sensitive data including restrictions such as ‘need to know’ principles.

☐Yes

☐No





C4 - (MANDATORY) Payload Encryption – TBA


TBA

☐Yes

☐No


C5 - (MANDATORY) Encryption Key Management

This requirement seeks to minimise the risks of compromised encryption keys.

You need to demonstrate that a policy or process in place to govern the use of your encryption keys in line with the Australian Government ISM.

The scope of this policy should cover three categories:

asymmetric/public key algorithms hashing algorithms symmetric algorithms


An internal policy document which covers the scope of encryption key management.

This document should include details relating to:

generation distribution storage access renewal revocation rotation archiving length and complexity of keys destruction of compromised

encryption keys recovery

☐Yes

☐No


C6 - (MANDATORY) Audit Logging

This requirement seeks to ensure traceability of access and actions.


Sample of a dummy access and event audit log

☐Yes

☐No



Audit logging should include both application level (access logs) and event based actions.

Consider your environment and what logging should be implemented and 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 Data identifiers (product ID, Tax

File Number (TFN)).

A data dictionary that describes the data attributes and maps against key audit log components


C7 - (MANDATORY) Product ID in Message HeaderDSPs with multiple products will need one product ID per product.


This requirement does not apply to SuperStream messages or Sending Service Providers.


Screen shot of the product ID in the message header

☐Yes

☐No


C8 - (MANDATORY) Self-Certification or Independent Certification:

The self-certification and independent


Self-Certification

Completed documentation

☐Yes

☐No

☐In


certification requirement seeks to provide the ATO with a level of assurance that you have robust security practices in place across your organisation.

This is done by way of self-certification or independent certification against one of the approved standards based on the below requirements:

Low volume of taxpayer or superannuation records (<10,000) AND consumes no/low risk APIs only can self-certify against:

iRAP ISO/IEC 27001 SOC2 OWASP ASVS 3.0 or

latest version Low volume of taxpayer or

superannuation records (<10,000) AND consumes medium or high APIs can self-certify against:

iRAP ISO/IEC 27001

Highly leveraged or high volumes of taxpayer or superannuation records (>10,000) must complete an independent certification against:

iRAP ISO/IEC 27001

demonstrating your conformance with the requirements (full control suite) of one of the approved security standards.

Independent Certification

Statement of Applicability and letter of compliance or copy of certificate upon completion of certification.

If seeking conditional approval for independent certification:

Letter of Engagement with a start date, completion date, scope of work and assessor details

progress


C9 - (MANDATORY) Supply Chain Visibility (payload encryption)

The supply chain visibility requirement seeks to identify the entities and annotate their functional roles involved in the transmission of information from the system which generates the payload through to the ATO.


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

Entity name ABN

☐Yes

☐No


The functional roles within a supply chain are defined as:

Data Collector: Party responsible for the acquisition of data through user interface interaction or APIs

Data Validator: 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 and Extraction: Party responsible for performing analysis on data to extract a data sub-set or additional derived/calculated data

Data Transformer: Party responsible for change syntactic representation of data

Data Provider: Party responsible for the payload (which may be encrypted)

Data Transmitter: Party responsible for the message with the payload. (e.g. ebMS3/AS4 transmission).

Service provider role or function.

The supply chain visibility solution is being developed in the near future. Until then, interim measures are in place.


C10 - (MANDATORY) Data Hosting

This requirement seeks to limit the risk of access to taxation and superannuation related information by individuals no authorised to access – including foreign actors.

The use of an ASD certified hosting environment is recommended but not mandatory

Your product or service is required to be hosted onshore by default with offshore hosting arrangements managed by


Provider name Provider location (physical

address) Redundancy location

(physical address) Whether the provider is ASD

certified or assessed against another security standard

Off-shore data hosting

If you are storing data off-shore you

☐Yes

☐No


exception only. will need to contact the DPO in the first instance.


C11 - (MANDATORY) Multi-Factor Authentication

This requirement seeks to minimise the opportunity for unauthorised users to access taxation or superannuation related information.

MFA will need to be implemented at login for external users accessing the tax and super data of another individual or entity.

Or

Internal users who perform a privileged user role as defined by the Australian Government Information Security Manual (ISM) .

It will need to include a combination of 2 of the below factors:

Something you know Something you have Something you are

There are examples of Authentication factors in the ACSC Implementing MFA (April 2019)


User manual, user description or instruction paired with screen shots of the user interface

☐Yes

☐No



https://www.cyber.gov.au/publications/multi-factor-authentication




C12 - (MANDATORY) Security Monitoring Practices

This requirement seeks to detect and respond to cyber-attacks, channel misuse and business threats


Network / Infrastructure layer – relevant combinations of the below:

Screen shots (product page, the management console page)

Product purchase/ownership doco (e.g. receipts, front page of a contract of product/support/service)

Configuration files Photos of the product Photos of SOC/SIEM centre

(using the products)

Application layer – relevant combination of the below:

Screen shots of the function page in the application


Transaction (data) layer – relevant combination of the below:


Previous unusual cases

☐Yes

☐No


Section D – Sending Service Providers (SSP) only

D1 - (MANDATORY) Will you be providing your solution(s) to market or using it to service your own commercial products?[Your response here]

D2 - (MANDATORY) What are the functional roles within the supply chain that your SSP solution(s) will perform?[Your response here]

D3 - (MANDATORY) Will your SSP solution(s) be providing an API connection, upload functionality or both?[Your response here]

D4 - (MANDATORY) Will your SSP solution(s) be using the same infrastructure, architecture and technology as existing commercial product(s) or gateway solution.

If not, please clarify any differences.[Your response here]


Section E – DSPs with an add-on marketplace only If you answered yes to having an ‘add-on marketplace’ question in section A, please supply the following information. We define an ‘Add-on marketplace’ as an: API that is offered by a DSP, for use by other third-party software developers to provide additional value added services to end customers. An add-on connects to a DSP via API - and is not taxation, accounting, payroll or superannuation software, note sending service providers/gateways are excluded.

E1 - (MANDATORY) Do you have security controls in place to govern 3rd party add-ons that have access to your APIs - Yes/No?

If yes, please provide details on the security standard you adopt, this can include a hyperlink to the relevant control.

Whilst the ATO does not prescribe or mandate the security standard you to apply to your 3rd party add-ons, we can recommend that you consider the ABSIA Security Standard for Add-on Marketplaces (SSAM) as a baseline.

[Your response here]


While not exhaustive here are some practical examples of add-ons that could be part of a marketplace: Accounting/taxation: inventory management, CRM, receipt OCR scanning Payroll: timesheets, rostering, employee on-boarding, pay calculator Superannuation: audit integrations, share registries, bank feeds

https://www.absia.asn.au/industry-standards/addon-security-standard/

https://www.absia.asn.au/industry-standards/addon-security-standard/

E2 - (MANDATORY) Please provide a list of your 3rd party add-ons with more than 1,000 Australian business connections and/or a connection to an Australian tax agent/practice.

The list should include the: 3rd party developers name Hyperlink to their product

An attached spreadsheet is the preferred format for the list.

[Your response here]

Submitting your questionnaireThank you for completing the required sections of DSP Operational Framework Security Questionnaire.

Please submit your completed questionnaire and evidence to the Digital Partnership Office through either the Online services for DSPs or [email protected].

Operational Framework Terms and ConditionsFollowing approval for the Operational Framework there will be an expectation that the terms and conditions below are met.

1. The ATO must be notified of any changes to your business or product environment in relation to the information you supplied in your questionnaire. Failure to do so may result in your product being de-whitelisted. The ATO reserves the right to undertake ad hoc reviews to ensure DSPs maintain alignment to the requirements of the Operational Framework.

2. Monitoring is considered a joint responsibility between the ATO and the DSP. The ATO conducts monitoring at the network, application and transaction layers. If anomalies or areas of concern are identified, we may re-assess your whitelisting suitability. The ATO will generally contact you or your representative before making changes to your whitelisted status unless exceptional circumstances apply.

3. Where a breach is identified by any means e.g. monitoring, client advice, you must contact the ATO immediately to ensure appropriate action can be taken.

4. In line with standard industry practice, certification (both independent certification and self–certification) must be current. Where certification lapses before the review date below, you must take the appropriate steps to update and supply the ATO with a current copy of your certification.

5. There are a number of requirements that have outstanding technical solutions. For example - authentication, payload encryption and supply chain visibility. As these solutions are completed we will advise you of the further requirements for your implementation.


mailto:[email protected]


Document DetailsAttributes Details

Date Latest Release October 2019

Document Name Digital Service Providers Operational Framework Security Questionnaire

File Location Software Developers Website

https://softwaredevelopers.ato.gov.au/

Version History Version Changes Date Released

V0.1 Interim questionnaire updated February 2018

V1.0 Updated Questionnaire June 2018

V1.1 Updated links to Information Security Manual on Australian Cyber Security Council website

December 2018

V1.2 Updated questionnaire and requirement information March 2019

V1.3 Updated questionnaire, links and requirements information

June 2019

V1.4 Addition to Section A, asking if a DSP has an add-on marketplace. Section E added for DSPs with an add-marketplace.

October 2019


https://softwaredevelopers.ato.gov.au/

ato.gov.au

purpose - australian taxation office · web viewthe intent of this questionnaire is to develop a...

Documents