Policy amendment – Safeguarding information from cyber threats
PSPF Policy 10: Safeguarding information from cyber threats has been amended to reflect changes in language used in the Australian Government Information Security Manual (ISM). This change does not alter existing obligations.
The term ‘application whitelisting’, which is one of the Essential Eight strategies from Strategies to Mitigate Cyber Security Incidents, has been replaced with the industry accepted term ‘application control’.
Minor updates to guidance have also been made to reflect new applications and technology.
Policy review and interim advice – Robust ICT systems
We have started a review of PSPF Policy 11: Robust ICT systems. The review will focus on realigning the PSPF with ASD’s updated advice on the assessment and authorisation of systems using a risk-based approach.
The review provides an opportunity for us to:
- Deliver a new framework for ICT systems that process, store and communicate Government information. Replacing the existing certification and accreditation process for ICT system with a new framework that is consistent with the ISM’s six-step process and focuses on managing risks during the lifecycle of the system.
- Provide clearer guidance on related systems and services, such as cloud services.
Keep an eye on our Protective Security Policy GovTEAMS site for further information.
Interim advice
In the meantime, the obligation for entities to manage the risks associated with their ICT systems remains the same.
Entities are still required to ensure that before processing, storing or communicating Government information (including sensitive and classified information) on an ICT system, the entity has assessed and accepted the residual security risks to the system and information in accordance with the Australian Government Information Security Manual (ISM).
For the remainder of 2019-20, we recommend that entities follow the ISM’s guidance to use a risk-based approach to assess and authorise ICT systems. However, entities may choose to continue with the current certification and accreditation guidance provided in the PSPF.
Impacts on 2019-20 PSPF reporting
For 2019-20 PSPF reporting purposes there is no significant change. Regardless of whether the entity has applied the certification and accreditation process or used the authorisation of systems process; both achieve the same result of managing the risks associated with the ICT system.
| Ad hoc | Developing | Managing | Embedded |
|---|---|---|---|
| Partial security measures are in place for ICT system development. Management of ICT systems certification and accreditation (or assessment and authorisation) is ad hoc and partially implemented in accordance with relevant ISM technical standards when operationalised. | Security measures are substantially in place for ICT system development. Certification and accreditation (or assessment and authorisation) of ICT systems is in accordance with ISM technical standards when operationalised. | Security measures are applied during all stages of ICT system development. ICT systems are certified and accredited (or assessed and authorised) in accordance with ISM technical standards when operationalised. | ICT security measures, including ICT system certification and accreditation (or assessment and authorisation) are in accordance with the ISM technical standards. The entity excels in proactively exploring opportunities to further improve ICT security protections in response to ICT security threats. |
Policy update – Management and structures and responsibilities
PSPF Policy 2: Management structures and responsibilities has been updated to reflect the change of relocating Requirement 3 Reporting security incidents and related guidance, relating to entities' obligation to report significant security incidents to the Attorney-General's Department, the relevant lead security authority and other affected entities to PSPF Policy 5: Reporting on security, Requirement 2 Reporting security incidents.
Policy update – Reporting on Security
PSPF Policy 5: Reporting on security has been updated to include three new supporting requirements including mandating the use of the PSPF online reporting model and PSPF offline reporting template for annual reporting on security, reporting security incidents (relocated from PSPF Policy 2) and entities to complete the annual ASD cyber security survey.
Updates to guidance include: reference to the PSPF reporting portal with details on the information requested and the steps required to complete the annual PSPF assessment report, use of the PSPF reporting data, and minor changes to the Annex A PSPF Maturity Self-Assessment Model in response to recent policy changes (Policies 5,9,10, 11 and16).
PSPF 2019 – 20 assessment reporting
The PSPF 2019-20 assessment period is fast approaching. The updated 2019-20 PSPF assessment questions will be distributed to reporting entities in June 2020 and access to the PSPF reporting portal will commence from 1 July 2020. Due to the impacts of the COVID-19 pandemic on working arrangements the submission date for the 2019-20 PSPF assessment report has been extended from 31 August 2020 to 30 September 2020.
In response to feedback from the 2018-19 PSPF assessment period a number of updates have been made to the PSPF reporting portal to enhance functionality and to provide more comprehensive guidance to assist entities to complete their assessments.
A reporting information session will be available to entities detailing these updates and to provide effective reporting insights to assist in completing the 2019-20 PSPF assessment report. The Protective Security Policy team are still working through what these information sessions will look like in these unprecedented times, however will provide further advice in the coming week.
Policy 8 – Annex G – Email protective marking standard
Minor edits have been to tables 6 and 21 to show the preferred application for the protective marking OFFICIAL: Sensitive in the subject line, which is [SEC=OFFICIAL:Sensitive].
As some entities may have applied the previous examples (ie adding a space between OFFICIAL: Sensitive in the subject line), we recommend that you configure your gateway rules to allow incoming emails with both syntax approaches (ie space and no space).