DSP Operational Framework Digital Service Provider Webinar Presented

DSP Operational Framework Digital Service Provider Webinar Presented by: Martin Mane Digital Partnership Office, ATO 28 February 2018

WHAT WE WILL COVER | DSP OPERATIONAL FRAMEWORK Overview of the DSP Operational Framework Creating a multi dimensional assessment process Categorising the risk of our APIs Consultations Requirements Transition and Timeframes Future of the DSP Operational Framework UNCLASSIFIED: Webinar – DSP Operational Framework 2

OVERVIEW | DSP OPERATIONAL FRAMEWORK The Digital Service Provider (DSP) Operational Framework (the Framework) is part of the ATO response in recognising and responding to risks posed by application programming interface (API) based wholesale digital services. Through the implementation of ATO APIs and services, DSPs make a range of taxation and superannuation related services available to the community. The ATO is at the forefront of API exposure and is significantly more advanced than other revenue agencies. Due to the sensitive nature of information consumed, there is a significant level of risk in releasing these services without adequate security measures in place. Why are we doing this The software industry is growing, we are witnessing a diverse range of developers entering the market and seeking to consume ATO APIs. As such, the ATO recognises we are creating new opportunities, the Framework aims to strengthen the security of the digital taxation and superannuation ecosystem by establishing a level of confidence and certainty. The Framework will enable the ATO to continue to invest in and extend the services made available through our digital wholesale channels. Securing the ecosystem will also provide increased levels of confidence to tax professionals, businesses and individuals. Furthermore, the ATO will publish each DSPs high level conformance outcomes, enabling full transparency and increased levels of comfort for potential and existing users. Factors creating a “COMPOUNDING EFFECT” in API services Exponential increases in opportunities (GOOD & BAD) Increased community connectivity & demand for availability (more access “anytime”) Increased range in types of APIs available (including data IN & data OUT) Significant increase in opportunities for enhanced client experience Exponential increases in volumes & payloads of API transactions Significant growth in the range, number & complexity of digital service providers Increased digital enrolments & consumption (e. g. by businesses, agents, others) Increased throughput velocity in ATO (i. e. more transactions are processing in real time) Increased automation in community & by service providers (enables “mass” volumes) UNCLASSIFIED: Webinar – DSP Operational Framework The compounding factors of API growth creates positive & negative opportunities. Significant increase in opportunities for cyber crime 3

CREATING A MULTI DIMENSIONAL ASSESSMENT PROCESS | DSP OPERATIONAL FRAMEWORK The DSP Operational Framework considers assessment in three dimensions. These are detailed below. Low Risk 4 3 Access granted Potential access with additional conditions Access denied or revoked 2 Insufficientl y mature 1 Minimal Risk Low Medium Risk DSP Risk Rating Se Mo curi nit ty or ing API Risk Category High Risk High Ris. Sufficientl k y mature API Risk Category DSP Risk Rating Security Monitoring Maturity The ‘API Risk Category’ assigned to an API is The ‘DSP Risk Rating’ is initially determined by The ‘Security Monitoring Maturity’ rating shows critical to the 3 D assessment model. It the registration and certification processes. It how a sufficiently mature capability would determines the minimum conditions required is based on the characteristics of the product adequately detect and defend ATO systems to consume the API. or service offered to clients (e. g. cloud vs from the compounding effects of API growth. desktop, tax professional vs business, client The API is risk categorised with the business base etc). area that requested the service/API. UNCLASSIFIED: Webinar – DSP Operational Framework We are currently investing in additional toolsets and resourcing to enable more APIs to be It is reviewed on an as needs basis (e. g. exposed and managed for the growing range of changing DSP circumstances, breach events). DSPs. 4

CATEGORISING THE RISK OF OUR APIs | DSP OPERATIONAL FRAMEWORK As part of the Operational Framework, the ATO has categorised its APIs. Categorisation is based on the characteristics and potential fraud that could occur through consumption of the API, such as the sensitivity and type of content. There may be more conditions placed on DSPs accessing ‘high risk’ services than those accessing ‘no risk’ services. The chart below highlights the characteristics of API risk ratings and provides examples of APIs that fit that category. 4. High risk API • Request results/could result in updating personal or sensitive client data. • Response contains/could contain personal or sensitive client data, not provided as part of the users request. 3. Medium risk API • Request results/could result in viewing or updating of a clients tax or super account data. • Response contains/could contain personal or sensitive client data, provided as part of the users request. Examples • View, update address, contacts, bank accounts. • Fund validation service get • Make a payment plan (could update FIA) • Lodge ITR, FBT (could update FIA and name) • Super. TICK and Employer. TICK Examples • Account, transaction, lodgement list • Outcome of assessment data • Lodge an Activity Statement or excise return • Add client/agent relationship • Submit deferral request • Response validates personal, sensitive or private client data by way of interaction with the client register or ATO systems. 2. Low risk API • Initial registration where the request or submission results in creating registration data in the client register or ATO systems. • Request results/could result in viewing or updating tax or super registration data. • Request results in providing account data attached/captured in ATO systems. Examples • Add a tax role • View AS role • Apply for ABN or AUSkey • Check ABN registration progress • 3 rd party transfer of data to ATO • TFN decs, TPAR, Payment Summary • Response contains no personal or sensitive client data and does not confirm by validation. 1. No risk API • Access to data that is generic/intended to be publicly available. UNCLASSIFIED: Webinar – DSP Operational Framework Examples • Fund validations service list • ABR Entitlement Questionnaire 5

CATEGORISING ATO APIs|DSP OPERATIONAL FRAMEWORK In consultation with key stakeholders from business, ATO APIs have been classified based on the characteristics of each service. The following is a sample of services: Service Name Service Description API Risk Rating Justification Client Communication List This service allows a registered agent to request and retrieve a historical record of client communications for a single client, multiple clients or all clients. 4 This service allows Agents to return a list of correspondence for all clients in the practice. Service will return TFNs for individual clients in the list, not provided as part of the original request. Client Update Financial Institution Details This service allows a reporting party or an intermediary to update a client's financial institution details. 4 This service has the potential to update personal or sensitive information (FIA details) Individual Income Tax Return This service allows for the lodgment of an Individual Income Tax Return, along with any relevant associated schedules. 4 This service has the potential to update personal or sensitive information such as FIA or address details. Account List This interaction allows an initiating party to request a list of ATO account information for a particular client, which can be forecasted to a future date for penalties and interest. Accounts can also be requested by account identifier, account type or account category. 3 This service will provide the ability to view account information. The identifier used as part of the request will also be returned i. e. the TFN entered will be returned with the response. Client Update Relationships Add This service will allow client to agent relationship/s to be added at the client level and/or account level. 3 This service updates non financial account information. It will also validate personal or sensitive information included in the users request. Payroll Event 2016 This services allows a business or their registered agent to notify the ATO of the payments made to the business' employees and the related Tax and Super obligations 2 This service allows an employer to send a form to the ATO. This form attaches to the client record and no response is provided to the client beyond acknowledgement of successful transmission. ABN Registration Application This service allows an application to be submitted with the ABR for an ABN/ TFN (TFN only for non-individuals). Bundled registration also support the inclusion of optional registration for tax roles. 2 This service returns a message providing a reference number and other optional items, such as the ABN in the case of a successful ABN application. TFN Declaration This service allows for the lodgment of a tax file number declaration/s by an Employer or their intermediary. 2 This service allows an employer to send a form to the ATO. This form attaches to the client record and no response is provided to the client beyond acknowledgement of successful transmission. ABN Entitlement Questionnaire This interaction allows a party to requestions to be answered in order to apply for an ABN. 1 This service returns publicly available information which can be accessed through the ABR The ABN Registration Help Service is a service that can be used to retrieve help details on completing the ABN Registration Service. UNCLASSIFIED: DSP Operational Framework ABN Get Help Context 6

CONSULTATIONS| DSP OPERATIONAL FRAMEWORK The ATO identified 5 key areas which required a position in order to close known gaps in the security of our environment. These areas are: • certification and assessment • multi-factor authentication • onshore-offshore data hosting • supply chain and • encryption. Focus groups including DSP and industry representatives were established to formulate these positions including how to transition existing DSPs. The solutions needed to strike the right balance between what is viable for DSPs to implement and maintain while still satisfying the risk appetite of the ATO. From these consultations the requirements were determined and agreed to. 51 Business and Industry representatives in total attended across 8 Industry Consultations We have and 4 micro focus consulted with groups a wide range of stakeholders 17 ATO Senior Executives from 11 branches 16 other Government Agencies May 2017 – December 2017 UNCLASSIFIED: Webinar – DSP Operational Framework 7

REQUIREMENTS|DSP OPERATIONAL FRAMEWORK This is a tiered model that considers: who hosts the software (client or DSP), how the software connects to the ATO, the risk profile of the API being consumed and the volume of taxpayer or superannuation records. Different requirements apply based on these characteristics. The registration process and security questionnaire will guide DSPs as to what requirements they need to meet and what evidence they need to provide. Hosted by the DSP Hosted by the Client Characteristics Direct connection to the ATO Connects to ATO via a DSP (eg Gateway) Certification Self-assessment Optional against: • i. RAP, • ISO 27001, • OWASP ASVS 3. 0 or • SOC 2 Holds or transacts Consumes low volumes of low risk APIs taxpayer or superannuation records Consumes Self-assessment medium to against: high risk APIs • i. RAP or • ISO 27001 Holds or transacts significant volumes of taxpayer or superannuation records Multi-factor Authentication Multi-factor Credential Required Onshore/ Offshore Data Hosting Supply Chain Visibility N/A Encryption in transit Encryption at rest Payload Encryption in transit required Optional N/A Solution to be developed Onshore by default with exceptions Solution to be developed Encryption at rest required Security Monitoring Required if DSP is using web services (hybrid desktop) N/A Security Monitoring is required. Independent assessment against: • i. RAP or • ISO 27001 Controls applicable to all DSPs • Registration process /questionnaire • Software identifier in message • Audit Logging – minimum standard • Personnel Security • Encryption key management plan 8

REQUIREMENTS| DSP OPERATIONAL FRAMEWORK Certification and assessment To provide the ATO with a level of assurance that DSPs have robust security practices in place, the ATO has drawn on government and industry best practice to determine DSP certification requirements. The requirements for certification and assessment will vary and are dependent on the: • type of service / software a DSP provides (desktop or cloud) • API risk rating of the digital service a DSP is seeking to consume (minimal, low, medium or high risk) • volume of accessible individual taxpayer or superannuation related records. Based on the combination of the above dependants, one of the following three actions will be required: • self-assessment performed by a relevant internal representative in line with ISO / IEC 27001, ASVS 3. 0 or SOC 2 • self-assessment performed by a relevant internal representative in line with ISO / IEC 27001 • independent assessment performed by a qualified, registered assessor in line with i. RAP or ISO / IEC 27001. DSPs are able to request to use an alternative security standard if they feel it would be more suitable for their circumstances. These requests will be assessed on a case-by-case basis. Evidence: Certification • i. RAP letter of compliance or i. RAP assessor engagement details, • ISO 27001 documentation and Certificate of Compliance / Registration or Statement of Applicability with Certificate of Compliance, or • Evidence of OWASP ASVS 3. 0 or SOC 2 assessment UNCLASSIFIED: Webinar – DSP Operational Framework 9

REQUIREMENTS| DSP OPERATIONAL FRAMEWORK Multi factor authentication Access to systems and the information they process, store or communicate need to be controlled through strong user identification and authentication practices. Multi-factor authentication uses independent means of evidence to assure a user’s identity. The three authentication factors are: Something one knows, such as a passphrase or a response to a security question, Something one has, such as a passport, physical token or an identity card, Something one is, such as biometric data, like a fingerprint, voiceprint or face geometry. Any two of these authentication factors must be used to achieve multi-factor authentication. If something one knows, such as the passphrase, is written down or typed into a file and stored in plain text, this evidence becomes something that one has and can defeat the purpose of multi-factor authentication. Authentication requirements will align to the Digital Transformation Agency's (DTA) Trusted Digital Identity Framework (TDIF) which is currently being developed. After the TDIF is established, DSPs will be required to either: • use the current Cloud Authentication and Authorisation (CAA) solution with the addition of a multi-factor credential • consume the government provided TDIF credential • become a TDIF credential provider in their own right and consume their own credential. While the TDIF standards and solutions are being developed for use in software products the following requirements will be introduced: • DSPs will need to review their security credential risks and develop a plan to manage the risks identified • DSPs providing cloud services will implement a multi-factor credential solution or provide assurance of sufficient controls (to be considered on a case by case basis). An example of sufficient controls may be the use of real time authentication heuristics that inform how transactions are managed. TDIF credentials will provide multifactor authentication. Many DSP products and or services perform tasks outside of the tax and superannuation space. Multi-factor authentication will not be mandatory for users who will never be exposed to tax and superannuation records. Desktop or on premise software should have a user account with some form of authentication. Solutions that are targeted at clients with a higher volume of records should have more robust authentication solutions and controls (e. g. brute force prevention, account timeout and lock-out). Evidence • Published product description • User manual, user description, user instructions paired with screen shots of the user interface UNCLASSIFIED: Webinar – DSP Operational Framework 10

REQUIREMENTS| DSP OPERATIONAL FRAMEWORK Onshore/Offshore data hosting Storing data in a foreign jurisdiction presents additional risks that must be considered. By default, the ATO expects DSPs to store data onshore. Consistent with guidelines for Australian, Prudential Regulation Authority (APRA) - regulated entities, the ATO expects DSPs to apply a cautious and measured approach when considering retaining data outside the jurisdiction it pertains to. APRA’s Cross Industry Prudential Practice Guide CPG 235 -Managing Data Risk, 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, • A detailed risk assessment, • A detailed understanding of the extent and nature of the business processes and the sensitivity/criticality of the data impacted by the arrangement, • A business case justifying the additional risk exposures. Consistent with APRA’s Prudential Standard Guide SPG 231 -Outsourcing, the ATO expects that DSPs would address the following specific risks and any other identified risks by: • Country risk: the risk that overseas economic, political and or social events will have an impact upon the ability of an overseas service provider to continue to provide an outsourced service to the DSP, • Compliance (legal) risk: the risk that offshoring arrangements will have an impact upon DSP’s ability to comply with relevant Australian and foreign laws and regulations (including accounting practices), • Contractual risk: the risk that a DSP’s ability to enforce the offshoring agreement may be limited or completely negated, • Access risk: the risk that the ability of a DSP to obtain information and to retain records is partly or completely hindered. This risk also refers to the potential difficulties or inability of the ATO to gain access to information using ATO information gathering powers, and • Counterparty risk: the risk arising from the counterparty’s failure to meet the terms of any agreement with the DSP or to otherwise perform as agreed. • The ATO expects that an offshoring arrangement would typically include a provision around security and confidentiality of information. Additionally, where you are storing data outside of Australia you must: • Make it clear to your 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 (eg clients of tax practitioners, employees, etc. ), on where and how their data is being managed Evidence • Name of ASD certified data hosting provider, or data hosting providers details, including: • provider name, • provider location (onshore / offshore), • redundancy location • If data is stored offshore further evidence is required. See Additional conditions for offshore data hosting below for more information. UNCLASSIFIED: Webinar – DSP Operational Framework 11

REQUIREMENTS| DSP OPERATIONAL FRAMEWORK Encryption The following encryption standards have been established: • Encryption of data in transit • Mandatory for all transmissions over public or shared network infrastructure to use ASD Approved Cryptographic Algorithms and Protocols. In majority of cases this will be TLS v 1. 2. • Encryption of data at rest • DSPs to use either full-disk, container, application or database Level encryption techniques, using ASD Approved Cryptographic Algorithms and Protocols. • Payload-level encryption • Encryption should be considered in conjunction with non-repudiation and integrity between the parties (via digital signatures). • The encryption mechanism should be payload and messaging agnostic. • Cryptographic Message Syntax (CMS) will form the basis of the solutions with a local customisation profile as required. Refer to page 242 - 247 of the Australian Government Information Security Manual for the ASD Approved Cryptographic Algorithm standards. Payload Encryption 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. DSPs must, at a minimum, implement either payload encryption or supply chain visibility requirements when the solution is made available. Evidence Relevant combinations of: • Screen shots (of the configuration page), • Configuration files, • Product data sheet/white papers (together with Product purchase/ownership documentation such as receipts, front page of a contract of product/support/service), • Federal Information Processing Standard Validation documents (US government computer security standard, e. g. FIPS 140 -2), • Product Common Criteria Evaluation documents, or • Product Evaluation Assurance Level (EAL) documents UNCLASSIFIED: Webinar – DSP Operational Framework 12

REQUIREMENTS| DSP OPERATIONAL FRAMEWORK Supply chain visibility A design principle of annotating the identity and functional role to the message is applicable to DSPs that read or modify sensitive data, where the payload is not encrypted end-to-end (e. g. payload-level encryption). The functional roles within a supply chain have been 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 Transformer Party responsible for changing syntactic representation of data Data Analysis and Extraction Data Integrator Party responsible for combining data from multiple sources for use Data Provider Party responsible for the payload (which maybe encrypted) Party responsible for performing analysis on data to extract a data sub-set or additional derived/calculated data Data Transmitter Party responsible for the message with the payload. (e. g. eb. MS 3/AS 4 transmission) Supply chain visibility will be part of a broader suite of controls, which includes audit logging, encryption, monitoring and certification of providers. When information is sent from one party to another (e. g. 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 below design principles and functional roles will inform the development of a future technology solution to deliver supply chain visibility. 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 (i. e. payload-level encryption). Where payload encryption has been implemented supply chain visibility will be optional. 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. UNCLASSIFIED: Webinar – DSP Operational Framework 13

REQUIREMENTS| DSP OPERATIONAL FRAMEWORK Security monitoring practices • Security monitoring should be implemented at different layers to detect anomalies and alert to indicators of fraud or misuse of a DSP product. It is expected that security monitoring will take place over three layers: Network/infrastructure layer • Application layer • Transaction (data) layer Software identifier in message The Product ID of the system that generates the original payload information (e. g. payroll or accounting system) for submission to the ATO rather than the intermediary (e. g. Sending Service Provider) that sends the ebms 3 message to the ATO must be included in the message header. Exceptions apply in the Super. Stream environment. Audit Logging – minimum standard We appreciate each DSP’s system is architected differently with limited universal design components. Standards for audit logging are therefore not in a prescriptive format – but rather based on a number of key components. DSPs should consider their environment and what logging should be implemented and ensure that the logging records include relevant details. Personnel Security Procedures are required to be in place for all DSPs. It is expected that DSPs can evidence this by providing internal policy documents including descriptions of the process. Note: DSPs that are micro-businesses (one or two employees) may not require personnel security procedures unless contractors or non-employees have access to source code or tax or superannuation related information. Encryption key management plan An encryption key management plan is required to be in place, including public key infrastructure (PKI) keys in line with ASD/Industry guidelines. UNCLASSIFIED: Webinar – DSP Operational Framework 14

TRANSITION AND TIMELINE | DSP OPERATIONAL FRAMEWORK The timeline below outlines key dates for existing DSPs to transition to the DSP Operational Framework including dates each requirement comes into effect. It is recognised 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. Implemented 1 March All existing DSPs wishing to consume PLS services will be expected to commence the approval process Transition Timeframes to meeting the requirements March 2018 Existing DSPS need to commence the process of obtaining certification April 2018 May 2018 June 2018 July 2018 1 April All existing DSPs wishing to consume STP services will be expected to commence the approval process 1 May All existing DSPs wishing to consume taxation related services will be expected to commence by the approval process 1 June All existing DSPs wishing to consume superannuation related services will be expected to commence the approval process 1 July Any DSP that does not fall into prior categories will be expected to commence the approval process 31 March DSPs consuming tax practitioner products and services must implement MFA Encryption at rest/in transit Onshore/Offshor e data hosting Personnel security measures 30 June DSPs consuming tax practitioner products and services must mandate the use of MFA 30 June Products and services where users have access to large volume of tax and superannuation records, DSP must implement MFA 1 July All products and services will be required to have audit logging capabilities Sept 2018 30 September All other products and services hosted by the DSP, MFA must be implemented 30 September Products and services where users have access to large volume of tax and superannuation records, DSP must mandate the use of MFA Dec 2018 31 Dec All other products and services hosted by the DSP, the use of MFA must be mandated Design for the supply chain visibility solution is expected to be completed by end of 2018 Design for the payload encryption solution is expected to be completed by end of 2018 Software identifier in message header UNCLASSIFIED: Webinar – DSP Operational Framework 15

FUTURE | DSP OPERATIONAL FRAMEWORK The DSP Operational Framework is a maturity model and will continue to evolve to meet the needs of emerging technologies and changes in the DSP environment. Monitoring and information incidents Monitoring is considered a joint responsibility between the ATO and DSPs. 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. This may include increasing the requirements that you need to meet or introducing additional requirements. The ATO will generally contact you or your representative unless exceptional circumstances apply. Where you identify a breach through your own monitoring controls you must notify the ATO immediately via your Account Manager to ensure appropriate action can be taken. Notifiable Data Breaches DSPs need to be aware of The Notifiable Data Breaches (NDB) scheme under Part IIIC of the Privacy Act 1988 that establishes requirements for entities in responding to data breaches. Entities have data breach notification obligations when a data breach is likely to result in serious harm to any individuals whose personal information is involved in the breach. For further information on the Notifiable Data Breach scheme, please refer to https: //www. oaic. gov. au/privacy-law/privacy-act/notifiable-data-breaches-scheme. Changing circumstances and annual re-assessment The ATO must be notified via your Account manager of any changes to your business or product environment, in relation to the information you supplied in your questionnaire response. Re-assessments will be conducted annually. In line with standard industry practice, certification (both independent and self–assessed) must be current. The ATO also reserves the right to undertake ad hoc reviews to ensure DSPs maintain alignment to the requirements of the framework. Expectations in meeting the requirements The ATO expects all DSPs will meet and maintain the relevant requirements of the DSP Operational Framework. The ATO will endeavour to work through nonconformance issues with DSPs, however failure to address these issues will result in restriction of access to services or de-whitelisting. The SBR Conditions of Use enables the ATO to lawfully suspend or terminate any software product, report or information from access to the SBR channel. The ATO is committed to the protection of tax and superannuation information and will treat issues of non-conformance seriously. UNCLASSIFIED: Webinar – DSP Operational Framework 16