status update: operational framework...status update: operational framework briefing: strategic...

Status Update: Operational Framework

Briefing: Strategic Working Group

Presented by: Martin Mane Digital Partnership Office, ATO October 2017

Progressing the Operational Framework

1. ATO APIs have been risk rated (from no risk to high risk) according to the type of sensitive data contained in, or updated by the transmission.

This rating system has been implemented as part of the interim approach and will continue with the enduring framework.

2. The ATO identified 5 issues which equated to gaps in our understanding of the Digital Service Provider (DSP) operating environment. Each of

these issues, if not addressed correctly pose a level of risk to the ATO and could have significant impacts on the exposure of ATO APIs. These

issues are:

3. To commence addressing some of these issues, an interim assessment approach has been implemented, which includes seeking responses and

evidence on these issues as part of the certification and assessment approach. All new DSPs will be required to completed this interim

assessment and meet our current minimum requirements for these issues before they will be conditionally whitelisted.

4. The next steps are to determine an agreed ATO position for the enduring framework. Focus groups including DSP and industry representatives

have been set up to help formulate this position including how to transition existing DSP. The solutions will need to strike the right balance

between what is viable for DSPs to implement and maintain while still satisfying the risk appetite of the ATO.

2

OVERVIEW | OPERATIONAL FRAMEWORK

The Operational Framework is part of the ATO response in recognising and responding to risks posed by Application Programming Interface (API)

based wholesale digital services. 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.

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 and will need new frameworks and technologies that strengthen the security in the emerging

world of APIs.

Multi-factor Authentication

Onshore/offshore Hosting Arrangements

Supply Chain Visibility

Encryption in Transit Certification and Assessment

UNCLASSIFIED: Briefing: ATO Operational Framework

EXPONENTIAL GROWTH OF APIs | OPERATIONAL FRAMEWORK

*500 + *400

237 70

2017 2018 2019 2020 2014

Application Programming Interfaces (API’s)

*500+ *450

*400 346

17

2020 2017 2018 2019

Digital Service Providers

2014

*20bn+

*10bn

*1bn 12.5m 0.14m

2020 2017 2018 2019

Transactions per annum

(SBR and SuperTick)

2013

0.9

5.7

14.8 17.3

22.4 22.4 22.4

0.5 0.5

0.5

0.5

0.5

0.5 0.5 0.5

1.3

1.3

1.6

1.4

1.3 1.6

8.6

0.5

2.7

7.5

17.0

19.2

24.2 24.5

31.5

Jul'16 Jul'17 Sep'17 Dec'17 Mar'18 Jul'18 Sep'18 Oct'19

STP PLS Super

Peak of Peak day volumes (millions)

0.6 3.4

8.9 10.4

13.4 13.4 13.4

0.2

0.2 0.2

0.2 0.2

0.2 0.2 0.2

0.1 0.1

0.1 0.1

0.1 0.1 0.4

0.2

0.8 3.7

9.2

10.6

13.7 13.7 14.0


STP PLS Super

Peak of Peak hour volumes (millions)

3.0 20.0 52.0 60.0

78.0 78.0 78.0

0.2

4.0

17.0

30.0 40.0

42.0 42.0 42.0

1.0

1.0

1.0

1.0

1.0

5.0

86.0

0.2

8.0

38.0

82.0 101.0

121.0

125.0

206.0


STP PLS Super

Required Transactions per second

* Indicative growth

Exponential Growth Demands for the SBR Channel (by quarter)

3 UNCLASSIFIED: Briefing: ATO Operational Framework

THE COMPLEXITY OF THE ENVIRONMENT | OPERATIONAL FRAMEWORK Software – ATO (no authorisation) Software – ATO Software – 3rd Party – ATO Software – Gateway – ATO Software – 3rd Party – Gateway – ATO

Software – cloud – ATO (no authorisation) Software – cloud – ATO Software – cloud – 3rd party – ATO Software – cloud – Gateway – ATO Software – cloud – 3rd Party – Gateway – ATO

This diagram represents the complexity of various use cases


Gateway

Authentication checkpoint

Enter software

Client record update

1

6

Submit Request

Success message via relevant providers

Whitelisting check

4

5

3rd party sending provider

3

2 Success message to user

7

In this scenario, a user of software transmits pay event reporting via the cloud and/or one or more 3rd party sending

providers.

1. The software user will log in to their software product using unique credentials. These credentials will not necessarily be passed to the ATO. DSP Software System Administrators are responsible for maintaining and tracking the user. If there are multiple DSPs, the ATO will not see authentication/authorisation/relationship of the originating software user.

2. The software consumes the ATO API to perform a specific action and/or actions through the software. The submission to ATO may include client identifiers e.g. TFNs, ABN, and Registered Agent Number.

3. The request travels through the cloud to one or more 3rd party sending providers (a type of DSP).

4. Authentication checkpoint: a valid 3rd party provider credential is required to transmit information to the ATO.

5. Whitelisting check: 3rd party sending provider will be checked to ensure they are whitelisted.

6. The client record is updated. In this case the payment summary is attached to the client record.

7. A success message is transmitted back to the software user via the relevant providers and the cloud.

Cloud

3rd party provider

ATO

Software

User

API Risk Category

2

SINGLE TOUCH PAYROLL USE CASE | OPERATIONAL FRAMEWORK

5

• The ATO will not know/see user authentication/authorisation/relationships at the originating point!

• ATO does not have visibility of multiple “deeper” DSPs in the supply chain!

• This API is “LOW” risk as sensitive data is only INBOUND. Risk can be managed via monitoring.


CREATING A MULTI DIMENSIONAL ASSESSMENT PROCESS | OPERATIONAL FRAMEWORK

The ATO Operational Framework considers assessment in three dimensions. These are detailed below.

DSP Risk Rating

The ‘DSP Risk Rating’ is initially determined by

the registration and on-boarding processes. It

is based on the characteristics of the product

or service offered to clients (e.g. cloud vs

desktop, tax professional vs business, client

base etc.)

It is reviewed on an as needs basis (e.g.

changing DSP circumstances, breach events).

API Risk Category

The ‘API Risk Category’ assigned to an API is

critical to the 3D assessment model. It

determines the minimum conditions required

to consume the API.

The API is risk categorised with the business

area that requested the service/API.

Access granted

Potential access with additional conditions

Access denied or revoked

Security Monitoring Maturity

The ‘Security Monitoring Maturity’ rating shows

how a sufficiently mature capability would

adequately detect and defend ATO systems

from the compounding effects of API growth.

We are currently investing in additional toolsets

and resourcing to enable more APIs to be

exposed and managed for the growing range of

DSPs.

6

1

3

2

4

AP

I Ris

k C

ate

gory

Sufficiently mature

Insufficiently mature

High Risk

Low Risk


APPENDIX

7

APPENDIX 1

CATEGORISING THE POTENTIAL RISK OF OUR APIs|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.

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) • SuperTICK and EmployerTICK

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.

Examples • Account, transaction, lodgement list • Outcome of assessment data • Lodge an Activity Statement or excise return • Add client/agent relationship • Submit deferral 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 .

• Response validates personal, sensitive or private client data by way of interaction with

the client register or ATO systems.

Examples • Add a tax role • View AS role • Apply for ABN or AUSkey • Check ABN registration progress • 3rd party transfer of data to ATO • TFN decs, TPAR, Payment Summary

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.

• Response contains no personal or sensitive client data and does not confirm by

validation.

Examples

• Fund validations service list • ABR Entitlement Questionnaire

1. No risk API

• Access to data that is generic/intended to be publicly available.


APPENDIX 2

CATEGORISING ATO APIs|OPERATIONAL FRAMEWORK In consultation with key stakeholders from business, ATO APIs have been classified based on the characteristics of each service.

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.

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.

4

Client Update Financial Institution Details

This service allows a reporting party or an intermediary to update a client's financial institution details.

This service has the potential to update personal or sensitive information (FIA details) 4

Individual Income Tax Return

This service allows for the lodgment of an Individual Income Tax Return, along with any relevant associated schedules.

This service has the potential to update personal or sensitive information such as FIA or address details. 4

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

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.

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.

2

TFN Declaration This service allows for the lodgment of a tax file number declaration/s by an Employer or their intermediary. 2

ABN Entitlement Questionnaire

This interaction allows a party to request questions to be answered in order to apply for an ABN. 1

This service updates non financial account information. It will also validate personal or sensitive information included in the users request.

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.

This service returns publicly available information which can be accessed through the ABR

ABN Get Help Context The ABN Registration Help Service is a service that can be used to retrieve help details on completing the ABN Registration Service. 1 This service returns publicly available information

which can be accessed through the ABR

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.

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.

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.

3

10

APPENDIX 3

DRAFT REGISTRATION AND ASSESSMENT|OPERATIONAL FRAMEWORK Product Security Questionnaire – This chart provides the types of evidence required to demonstrates DSP security posture and support questionnaire responses

Multi-Dimensional Risk Rating

High Medium Low Nil

Personnel Security Personnel security integrity process. Personnel security integrity process. Not required. Not required.

System / Product Certification

ISO 27001 Certificate of Compliance / Registration as evidence of a review undertaken by an independent assessor, with scoping documentation or statement of applicability,

Or, iRAP letter of compliance as evidence of a review undertaken by an authorised assessor.

ISO 27001 Certificate of Compliance / Registration as evidence of a review undertaken by an independent assessor, with scoping documentation or statement of applicability,

Or, iRAP letter of compliance as evidence of a review undertaken by an authorised assessor.

Self assessment in line with ISO 27001 Standard.

Not required.

Supply Chain Security If the product is not transacting directly with the ATO, the DSP must provide relevant details of the parties across the transactional supply chain.

if the product is not transacting directly with the ATO, the DSP must provide relevant details of the parties across the transactional supply chain.

If the product is not transacting directly with the ATO, the DSP must provide relevant details of the parties across the transactional supply chain.

If the product is not transacting directly with the ATO, the DSP must provide relevant details of the parties across the transactional supply chain.

Hosting Environment Security

Details of the data hosting provider are required.



Not required.

Client Authentication Threshold

NeAF level 3 (ability to transition to multi-factor authentication and know your client).

NeAF level 3 (ability to transition to multi-factor authentication and know your client).

NeAF level 2. NeAF level 1.

Data Protection at Rest Suitable practices in place. Suitable practices in place. Suitable practices in place Not required.

Data Protection in Transit Suitable practices in place. Suitable practices in place. Suitable practices in place Not required.

Encryption Key Management

Key management plan. Key management plan. Not required. Not required.

Security Monitoring Practices

Robust practices , an example that demonstrates monitoring across three layers , i.e . network, application, and transaction.

An example that demonstrates monitoring across two layers, i.e. network, application, or transaction.

A single example that demonstrates a basic monitoring capability

Not required.

DSP minimum evidence requirements are scalable and increase based on the API risk category


11

APPENDIX 4

MATURING THE MONITORING CAPABILITY | OPERATIONAL FRAMEWORK

11

Maturing the monitoring capability

In addition to DSP monitoring capability, we are growing our

capability to enhance:

• threat Intelligence - detect fraud and potential compromise

• real time monitoring - 24 hours, 7 days a week

• web threat detection - dynamically identify threats by monitoring

traffic across entire web sessions

• real time intervention - proactively blacklist users, challenge or

block transactions in-session.

Detect

Analyse

Protect Communicate

Support

Our Defence in Depth model

The nature of the information contained in our API transactions is a target for cyber crime including identity theft, data security breaches and fraud.

Tackling cyber crime is a joint responsibility between the ATO and DSPs .

Authentication and Authorisation - knowing who the user is

Controls that ensure information is only accessed by entities with a

need to know including:

• Only being able to access information where they have the

appropriate authorisations

• Holding valid credentials which are required to transmit

information to the ATO

• Credentials of an appropriate strength in relation to the risk

category of the API being used – including multifactor

authentication for higher risk APIs

Managing data breaches

Data breaches need to be actively managed to limit impact.

• Our Information Incident Management framework outlines

how we manage third party data breaches and acute refund

fraud events

• DSPs will also need processes to manage data breaches. DSPs

are required to notify the ATO of any suspected or actual data

breaches as soon as possible.


12

APPENDIX 5

ENCRYPTION| OPERATIONAL FRAMEWORK

12

it solves a security problem for

government and creates an opportunity

for business. A wholesale offering must

cater for both B2B and B2G channels

with one solution.

B

G

FEATURE 1 CHANNEL

with a consistent approach to encryption

regardless of message transport and data

format, a wholesale offering provides a

standard that remains build agnostic.

FEATURE 2 STANDARD

up to date with the latest ASD approved

cryptographic algorithms. A solution will

ensure currency by supporting the latest

evaluated protocols and algorithms.

FEATURE 3 CURRENT

the creation of a public key exchange

controlled by government that offers

revocation and an OCSP, will solve the

key distribution problem for industry.

FEATURE 4 SCALABLE

Encryption is a key component of hardening

the security of the operational framework

ecosystem and includes:

• Confidentiality between parties

• Non-repudiation

• Integrity (digital signatures)


Possible attributes for straightforward approval through the ATO interim Operational Framework to consume highest level risk category APIs

13

APPENDIX 6

SIMPLE DSP SCENARIO|OPERATIONAL FRAMEWORK

I have personnel security integrity processes in place.

My supply chain is simple. For example: • My product

interacts directly with the ATO

• My product does not expose data provided by the ATO to other DSPs or does not act as a pass through service to the ATO

I host my data onshore in an ASD certified environment or directly on the users desktop.

My product supports NeAF level 3 (multi-factor) authentication of the client

Data transmitted via my product is encrypted in line with an approved ASD Cryptographic Algorithm in transit and is also encrypted at rest.

I have a PKI management plan in place that meets ASD/industry best practice. I conduct security

monitoring at the network, application and transaction layers.

I have a current iRAP assessment or ISO certification

This process forms the baseline for a maturity framework that may evolve over time to include ‘know your client’ As an alternative interim arrangement: • Desktop – client uses ATO credential (AUSkey or any

replacement) • Desktop via cloud - uses the CAA process • Cloud - uses the CAA process

* sunset arrangements still to be determined


APPENDIX 7 CONSULTATION ROADMAP | OPERATIONAL FRAMEWORK

The timeline below outlines key dates and consultations held to present and obtain feedback on the Operational Framework.

June 2017 July 2017 Aug 2017

Interim approach

consultation with DSPs

Interim approach (IA) tabled with ATO

Exec - IA endorsed

continue work on threshold issues

May 2017

Presented at the ATO Security

Committee

Consult with DTA Chief

Information Officer

Workshop held with key ATO

stakeholders

Consult with Cyber

Security Working Group

Consult with Inspector General of Taxation

Consult with ATO

Senior Leaders

Consult with Australian

Tax Revenue Office

Consult with

Internal Audit

Consult with Cyber Security

Special Advisor to the

Prime Minister

Oct 2017 Sept 2017

Op

era

tio

nal

Fra

mew

ork

Targeted consults with

individual DSPs

Consult with

ANAO

Consult with

Cyber Priorities

Group

Consult with

Treasury


Operational Framework

Working Group

Meeting

APPENDIX 8 TIMELINE TO ENDURING APPROACH | OPERATIONAL FRAMEWORK

The ATO are currently working closely with a number of DSPs, industry associations and across Government to address 5 key issues identified through our

interim assessment:

1. Multi-factor authentication

2. Supply chain visibility

3. Encryption in transit

4. Onshore/offshore hosting arrangements

5. Certification and assessment (including transitioning DSPs to the updated process)

Note: Timelines for each of these are detailed on the following slides.

Endorsement of issues 1, 2 & 3

from Working Group

Endorsement of issues 1, 2 & 3

from key internal stakeholders &

ATO Security Committee

All DSPs required to

have relevant

certification[TENTATIVE]

TDIF Solution available. Transition

commences [TENTATIVE]

Re

solu

tio

n o

f ke

y is

sue

s

March July 2018

October December

Draft

*note consultation with DSPs to determine a transition period is occurring.

November

*Dates are correct as at 6 October 2017 15 UNCLASSIFIED: Briefing: ATO Operational Framework

Position on issues 1, 2 & 3

published. Implementation

commences

Endorsement of issues 4 & 5 from

key internal stakeholders & ATO Security Committee

Position on issues 4 &5 published.

Implementation commences

Draft Micro Group position

tested with focus group

Endorsement of issues

4 & 5 from Working

Group

Face-to-face Registration

and Certification micro group

meeting

Approval from ATO Exec

2017

APPENDIX 9 MULTI-FACTOR AUTHENTICATION | OPERATIONAL FRAMEWORK

Current draft ATO position: • DSPs will be required to adopt a Trusted Digital Identity Framework (TDIF) compliant solution when it is available. • Prior to TDIF implementation DSPs will be required to assess their existing credential solutions, potential risks and any mitigating controls currently in place.

DSPs will be required to develop a plan for managing the identified risks which will include implementing a MFA solution for cloud products.

Mic

ro F

ocu

s G

rou

p

Draft


*Dates are correct as at 6 October 2017

Second focus group

meeting

First focus group

meeting

Position on multi-factor

authentication published.


[PLACEHOLDER] Cloud DSP to

implement MFA solution or

provide assurance of sufficient

controls in place

July February


Working Group

Meeting

[PLACEHOLDER] TDIF Solution

available. Transition

commences

[PLACEHOLDER] DSPs to review

security credential risks and develop a plan to manage

risk.

Third focus group

meeting

5 one-on-one

meetings held with

DSPs

Endorsement from Working

Group

Endorsement from key internal

stakeholders & ATO

Security Committee

2018 August September October November December

2019

[PLACEHOLDER] TDIF Solution

available. Transition complete

2017 June


Current draft ATO position: • Encryption of data on the wire

− 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 v1.2.

• Encryption of data at rest − DSPs to use either Full-Disk, Container or Database Level encryption techniques, leveraging an ASD Approved Cryptographic Algorithm.

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

• Supply Chain Visibility − Design principles agreed.

Remaining decision: • Approach to verifying explicit pre-authorised supply-chain participants vs verification of role-based accreditation only. • Agree on the ABSIA defined functional roles within a supply chain. • Develop a solution to annotate DSP identity in messages through the supply chain

Mic

ro F

ocu

s G

rou

p

APPENDIX 9 SUPPLY CHAIN AND ENCRYPTION | OPERATIONAL FRAMEWORK

Draft



Second focus group

meeting

First focus group

meeting

Position on supply chain and

encryption published.


[PLACE HOLDER] All DSPs required to have relevant

encryption solutions in

place (on wire/ at rest/ payload)

June April


Working Group

Meeting

Third focus group

meeting to agree on outcomes


Group

2018 August September October November


stakeholders, & ATO

Security Committee

[PLACE HOLDER] Design and

requirements for payload level

encryption developed

2017 December


First focus group

meeting


Working Group

Meeting

2018 August September

Current draft ATO position: • ATO adopts an offshore country risk profiling approach whereby the offshore country risk, as prescribed by Australian Security Intelligence Organisation

(ASIO), is considered.

Remaining decisions: • Jurisdictional considerations to be resolved (inconsistent with current position) • Feasible timeframes for DSPs to adhere to the approach


Mic

ro F

ocu

s G

rou

p

APPENDIX 9 ONSHORE/OFFSHORE DATA HOSTING | OPERATIONAL FRAMEWORK

Draft


October


stakeholders, & ATO Security Committee




Group

November December 2017

Position on onshore/offshore

data hosting published.



Second focus group

meeting

First focus group

meeting

July


Working Group

Meeting

TDIF Solution available. Transition

commences [TENTATIVE]

Third focus group

meeting

2018 August September

Current draft ATO position: • Interim certification process in place (ISO, iRAP) • Digital Service Providers (DSPs) seeking to consume high risk API’s / services (risk categories 3 & 4) will be required to attain a level of certification to

manage the emerging cyber threats associated with exposing taxpayer data and strengthen the overarching security of the digital ecosystem. • Self-certification acceptable for risk category 2 APIs • The appropriate certification threshold has been defined as per the hierarchy below:

− Tier 1 Certification – Information Security Management (ISM) Guidelines The information security best practice standard for the Australian government is the Information Security Manual (ISM) developed by the Australian Signals Directorate. Assessment against this standard should be undertaken by a representative from the Information Security Registered Assessors Program (iRAP) This name has become synonymous with the assessment against the ISM. − Tier 2 Certification (Minimum Certification Threshold) – Information Security Management Systems The leading, internationally recognised, independent information security standard is the ISO/IEC 27000 family – Information Security Management Systems. Within the ISO 27000 family, ISO/IEC 27001 offers a high level, comprehensive view across a series of key controls. The level of technical detail examined in line with these controls is fewer than that of an iRAP assessment.

Remaining decision: • Feasible timeframes for DSPs to attain certification • Feasible timeframes for completing the security questionnaire

Mic

ro F

ocu

s G

rou

p

APPENDIX 9 CERTIFICATION AND ASSESSMENT | OPERATIONAL FRAMEWORK

Draft






Group

October November December

Face-to-face micro group

meeting

2017


stakeholders, & ATO Security Committee

Position on certification and

assessment published.



status update: operational framework...status update: operational framework briefing: strategic...

Documents