SEAD administrators instruction guide

The SEAD service enables government agencies engaging this service (referred to as ‘SEAD partners’), to inherit a self-contained environment, known as a 'SEADpod' within the cloud infrastructure that also underpins the ABS DataLab. Through self-service features, SEAD partners gain exclusive administrative control over this self-contained environment.

This guide is specifically tailored for SEAD administrators. Its purpose is to provide assistance in managing SEADpods by covering essential functions required for effective administration.

For information on the capabilities of SEAD user analysts in accessing and navigating the SEAD system, please consult the SEAD user guide. 

Note: The ABS does not provide guidance on how to conduct data analysis or modelling, or how to utilise the statistical tools available.

• Partner pod owners and administrators bear the responsibility of ensuring that the data used within SEAD is strictly for authorised purposes. 
• Partner pod owners and administrators are expected to inform their SEADpod users about their obligations under relevant legislation.
• For users and administrators handling ‘Protected’ level data, holding at least a baseline security clearance is mandatory. Note: While it is not obligatory for SEAD users and administrators dealing with ‘Official’ and ‘Sensitive’ level data, the ABS recommends that all SEAD partner administrators obtain at least a baseline security clearance. 

A Privacy Impact Assessment (PIA) has been conducted for SEAD and considers the potential impacts on people whose personal information may be used in a SEADpod. This information includes statistical records and microdata stored or analysed in a SEADpod, along with the personal information of SEADpod system administrators and users. The PIA determined that sufficient protections are in place to safeguard the privacy of SEAD users and the Australian community. 

ABS led security testing and patching is undertaken at 8-12 week intervals, alongside feature and performance enhancements. Consequently, approximately every 8-12 weeks, scheduled administrator outages occur. As part of this ongoing process, the ABS communicates with SEAD administrators via email to provide updates on system maintenance and enhancements. During these outages, certain administrative tasks may be restricted, but administrators will still have access to ingress and egress data. The ABS ensures that SEAD partners receive advance notice of up to 10 days regarding these planned outages. For further details, please consult the system security documentation.

The ABS will send important messages, notifications, and reminders to SEAD partners via email and will use the global banner messaging system within SEAD for communication. However, the ABS typically does not contact SEAD users directly, except through banner messages on the SEAD portal. It is essential that any necessary communications are relayed to SEAD users by their administrators. Users and administrators should check the 'What’s New' section of the SEAD web portal regularly for information on the most recent updates and enhancements.

The Five Safes Framework (Five Safes) is a multi-dimensional approach to managing disclosure risks. It presents specific questions to help assess each risk aspect (safe) in a qualitative way. The ABS uses the Five Safes to inform disclosure assessments for all data, including detailed microdata to evaluate whether a particular method of data access meets confidentiality and privacy requirements.

The Five Safes splits data access questions into five elements of control:

• Safe settings - Does the access environment limit unauthorised use?
• Safe people - Is the researcher authorised to access and use the data appropriately?
• Safe projects - Is the data to be used for an appropriate purpose?
• Safe data - Has appropriate and sufficient protection been applied to the data?
• Safe outputs - Are the statistical results non-disclosive?

SEAD enables partners to leverage the existing Safe settings protections maintained by the ABS, through the provision of a secure analytical cloud environment for access and storage of data. As a SEAD partner administrator, the remaining Five Safes controls fall within your responsibility and must be upheld through the following suggested mechanisms: 

Users provisioned with microdata access should be approved by the relevant administrators, governing bodies, or data custodians. Receiving appropriate training (including the ABS provided user guide) and agreement against designated conditions of access.

Projects should be accompanied by appropriate proposals, and agreements provided to administrators. Outlining public interest, business use and expectations for research and/or statistical purposes. 

Appropriate confidentialisation and treatments are applied to any form of data, code or packages, before made accessible to approved users.

All outputs are validated prior to release from the system, against organisational tolerances, to ensure appropriate governance and legal obligations are adhered to (for example, re-identification of an individual or organisation). 

The ABS upholds its Safe settings through extensive security protocols that keep personal information safe and secure. ABS systems that store and process statistical data comply with the Australian Signals Directorate's (ASD) Information Security Manual and are subject to Independent Security Registered Assessors Program (IRAP) certifications, ongoing security audits and robust IT security testing and patching. 

The SEAD system is hosted in Microsoft Azure and meets ‘Protected’ level security standards in line with the ABS System Security Plan. Microsoft is a trusted provider of cloud storage and analytics services and has been engaged by the ABS. For SEAD, the Microsoft arrangement ensures the ABS retains effective control of all microdata and user information.

The SEAD system uses closed network virtual machines (VMs) and cloud storage services to provide secure, isolated research spaces for the analysis of microdata. The technology underpinning the SEADpod includes data encryption at rest to mitigate against unauthorised access to microdata, Azure Storage Accounts to securely hold individual research products and allow querying from authorised users, and cloud servers (including backup servers) hosted exclusively onshore with no intention of being hosted internationally. Access to the system is only authorised for use in Australia unless approved by the ABS. Data is also backed up regularly (frequency dependant on the system, detailed throughout these instructions) to ensure appropriate recovery protocols in the event of an interruption to services.

The SEAD Product Storage Account is protected with Microsoft Defender for Storage which provides: 

• Threat detection / malicious/unusual behaviour detection, such as data exfiltration attempts. 
• Machine learning based and behavioural models. 
• Activity monitoring. 
• Credentials theft, lateral movement attempts. 
• Access token leakage, scanning by third parties. 

The ABS also uses the Cloud Security Posture Management (CSPM) tool – InsightCloudSec, which provides information about potential misconfigurations, configuration drift and any security issues following deployment of resources. Main focus areas are:

• Publicly accessible storage.
• Insecure/high risk network configurations (e.g., ingress from high risk ports, deprecated versions of TLS).
• Disabled security configurations (e.g., logging not enabled, encryption of data at rest, soft delete and purge protection status).

Although the SEAD system is contained within the cloud environment that underpins the ABS DataLab, it is separate to the ABS DataLab. ABS System Administrators will only interact with the SEADpod where required to practically deliver infrastructure services, but will not provide support on the use of analytical products. 

Note: Security testing and patching is undertaken at 8-12 week intervals alongside feature and performance updates. This is accompanied by an outage to the administrator interface that is expected to last for several hours. The ABS will inform SEADpod owners of the outage date up to 10 days in advance. Administrators can still view the SEAD administrator portal as well as ingress and egress data to pre-existing product shells, but will be unable to edit or create users, projects, products or organisations during the outage. Users should remain unaffected throughout, however, precautions should still be taken. 

SEAD should be utilised in a secure and safe setting, with remote access permitted under the following conditions:

• It must be used in a work or private location.
• The screen must be protected from oversight by any other person. This includes locking and password-protecting your screen, should you move away from your computer.
• A secure internet connection must be used:
  • A secure internet connection means any Wi-Fi that is password protected (e.g. work, home, your hotel room, hotspotting from your phone).
  • A non-secure internet connection means an open or public connection like a restaurant/cafe, airport, public transport, hotel lobby or shopping mall.
• Overseas access to SEAD is not permitted under any circumstances without written approval from the ABS.
• Working in the SEAD from home is supported by the ABS but you are responsible for checking and complying with your organisation's requirements for working from home.
• Do not use any type of internal messaging system which may have external server connections, or attempt to remove or copy data out of the system without the consent of your organisation.
• The SEAD screens are to be kept secure at all times whether you are working within your organisation or from home.

To view a full breakdown of SEAD roles, refer to Administrator functions on the SEAD website.

The Pod administrator role is functionally separated into 4 distinct roles: 

• Reader administrator - Has read-only permissions in the SEAD administrators interface meaning they have no access to editing functionality.
• Project administrator - Manages research projects for the pod, creates/closes/assigns users to projects in their Pod, link data products to projects.
• Data administrator - Creates or deletes products, uploads data to or removes data from product containers in the SEADpod's storage account, download analyst results or outputs from a projects Output or Project drive.
• User administrators - Registers and removes User accounts, can manage accounts like reset password, reset MFA.

Administrators are Reader administrators by default. Pod owners are able to assign administrators to any combination of the latter 3 roles in the SEAD portal. Information on viewing and editing administrator roles can be found under Managing administrators in the Pod owner actions page.

ABS system administrators hold an overarching administrator role but will not access partner SEADpods unless requested. 

To contact ABS system administrators please email sead.support@abs.gov.au. 

SEAD is enabled by Azure cloud infrastructure, which may be blocked by some organisations’ firewall settings. 

ABS cannot make changes to external organisations' infrastructure. SEADpod owners need to supply the information below to their organisation’s ICT department. If required, a Letter of Compliance can be supplied by the ABS upon request. 

Network/Cyber Security departments in each organisation need to review and may need to make changes to allow access. This only needs to be done once.

Contact sead.support@abs.gov.au if further assistance is required.

     1.     Enable authentication to the tenant

Users need to authenticate to one of ABS' Azure Active Directory tenants, which may be strictly controlled by government agencies and academic workplaces. If your environment implements Azure Tenant restrictions (using the Restrict-Access-To-Tenants header insertion) then you need to include the ABS SEAD Tenant:

Tenant ID

30be94bc-7211-46d1-a5a0-705e859fa489

Primary domain

absmydata.onmicrosoft.com

     2.     Allow user access to application URLs

Users will need to access the following URLs:

• Azure Active Directory: login.microsoftonline.com, go.microsoft.com
• SEAD line of business application: sead.abs.gov.au

     3.     Enable Desktop brokering HTTPS connections

Configuration to your organisation's network is needed to allow outbound connections to the following addresses required for Azure Virtual Desktop (AVD): 

• login.microsoftonline.com  
• *.wvd.microsoft.com  
• *.servicebus.windows.net  
• go.microsoft.com  
• aka.ms  
• learn.microsoft.com  
• privacy.microsoft.com  
• query.prod.cms.rt.microsoft.com  

All addresses utilise the TCP protocol and outbound port 443 for communication.  

To use the Desktop version of AVD, IT administrators may need to enable the 'Remote Desktop Client'. For further information on using AVD, please refer to 'Accessing your project workspace' in the SEAD user guide.

For uploading and downloading from Azure Files storage (for SEAD products and Project file shares). Some organisations choose to limit network access to a dedicated subnet/jumphost. ABS requires an IPv4 range to apply to the storage firewalls, which can match the organisations chosen location for upload/download to ensure security. Transfers can go via Azure Express Route Circuit if the organisation has configured a peering to this service, otherwise the traffic will traverse public internet. ExpressRoute, enables the creation of a defined route between Azure and your on-premises network that doesn't traverse the internet. Because ExpressRoute provides a dedicated path between your on-premises datacentre and Azure, ExpressRoute may be useful when network performance is a consideration. ExpressRoute is also a good option when your organization's policy or regulatory requirements require a deterministic path to your resources in the cloud.

Organisations can choose their preferred storage client such as Azure Storage Explorer (ASE) or AzCopy. However, the ABS does not provide support for the installation of client installed software, and will provide only limited network troubleshooting. Suggested communication requirements for ASE and AzCopy are listed below.

IMPORTANT: If the network you are connecting from is peered with an Azure VNET that is connected to an Azure Private DNS Zone for privatelink.file.core.windows.net, there is known limitation that will cause DNS resolution to fail. Contact your SEAD account manager to discuss alternative solutions.

1. Enable authentication to the tenant

Users need to authenticate to one of ABS' Azure Active Directory tenants, which may be strictly controlled by government agencies and academic workplaces. If your environment implements Azure Tenant restrictions (using the Restrict-Access-To-Tenants header insertion) then they need to add the ABS SEAD Tenant:

Tenant ID

30be94bc-7211-46d1-a5a0-705e859fa489

Primary domain

absmydata.onmicrosoft.com

     2.     Allow user access to URLs for Azure Storage Explorer / AzCopy

Required hosts:

• *.file.core.windows.net
• *.blob.core.windows.net
• *.dfs.core.windows.net
• login.microsoftonline.com
• go.microsoft.com
• management.azure.com

Note: Performance is not guaranteed due to factors such as network latency, bandwidth, and application behaviour.