<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dokAAPp xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../../../../prj/bin/GuidICS/dokAAPp.xsd">
    <author>
        <individual>
            <ind ini="pb" org="NIK" role="initiation coordination"/>
        </individual>
        <organization>
            <org kraj="Australia" nm="The Australian National Audit Office" skr="ANAO" www="www.anao.gov.au"/>
        </organization>
    </author>
    <about caseNumber="8" file="cyberIncidents" folder="C:\pb\Algorytm\SAI_robo\AU\2024\cyberIncidents" id="AU2024cyberIncidents" issueYear="2024" waga="364" wagaDepth="8" wagaBreadth="62" wagaRarity="17.57" wagaRecency="0.84" wagaRank="3" wagaRanked="52">
        <tyt>
            <tx file="cyberIncidents.pdf" l="en" nm="Management of Cyber Security Incidents" typDok="original_document"/>
        </tyt>
        <portfolio>
            <pfl zn="cybersecurity"/>
            <pfl zn="businessContinuity"/>
            <pfl zn="protectionOfInformation"/>
        </portfolio>
        <ver put="202610011905" stage="final"/>
    </about>
    <part id="lead">
        <tyt>
            <tx l="en" nm="Both agencies had a recovery plan, neither had ever tried it"/>
        </tyt>
        <narrative>
            <narr l="en">
                <ak nr="1">AUSTRAC watches the money moving through the Australian financial system; Services Australia pays Medicare, child support and aged care. Both run on systems a cyber attack could stop, and the government says its own entities should be cyber exemplars. In the year to June 2023 about 31 per cent of the incidents reported to Australia's signals directorate came from federal entities. This audit, tabled in June 2024, asked how the two would cope when one reached them. Both keep backups; neither had tested restoring them. From there: a recovery schedule that left out Medicare until a financial audit noticed, alerts passed on verbally, seventeen months of archived security data that could not be produced, and a data breach nobody reviewed afterwards.</ak>
            </narr>
        </narrative>
    </part>
    <part id="background" v="01">
        <tyt>
            <tx l="en" nm="Background"/>
        </tyt>
        <part id="scale">
            <tyt>
                <tx l="en" nm="Scale"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak tp="li">two entities examined - the financial intelligence agency and the government's main service delivery agency; 19 recommendations, all agreed</ak>
                    <ak tp="li">about 31 per cent of the cyber security incidents reported to the signals directorate in 2022-23 came from non-corporate Commonwealth entities</ak>
                    <ak tp="li">25 per cent of those entities self-assessed at Maturity Level Two across the eight prioritised mitigation strategies; 82 per cent reported holding an incident response plan</ak>
                </narr>
            </narrative>
        </part>
        <part id="compliance">
            <tyt>
                <tx l="en" nm="Compliance"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak tp="li">the whole-of-government protective security policy framework, which carries the mandatory requirements for managing cyber security incidents</ak>
                    <ak tp="li">the signals directorate's cyber security guidelines and its eight prioritised mitigation strategies</ak>
                    <ak tp="li">the public governance statute under which entities must apply that framework, and the audit statute the report is made under</ak>
                </narr>
            </narrative>
        </part>
        <part id="perfromance">
            <tyt>
                <tx l="en" nm="Performance"/>
            </tyt>
            <part id="economy">
                <tyt>
                    <tx l="en" nm="Economy"/>
                </tyt>
                <narrative>
                    <narr l="en">
                        <ak tp="li">the backup, logging and event-management solutions in place, and the assurance actually obtained from them</ak>
                        <ak tp="li">monitoring resources set against spending on preventive controls</ak>
                        <ak tp="li">data centres and backup media, and the protection measures documented for them</ak>
                    </narr>
                </narrative>
            </part>
            <part id="efficiency">
                <tyt>
                    <tx l="en" nm="Efficiency"/>
                </tyt>
                <narrative>
                    <narr l="en">
                        <ak tp="li">timeframes for triage, escalation and reporting to stakeholders</ak>
                        <ak tp="li">centralised against decentralised event logging</ak>
                        <ak tp="li">retrieval of production and archived security event data</ak>
                    </narr>
                </narrative>
            </part>
            <part id="effectiveness">
                <tyt>
                    <tx l="en" nm="Effectiveness"/>
                </tyt>
                <narrative>
                    <narr l="en">
                        <ak tp="li">readiness to maintain business continuity after a significant or reportable incident</ak>
                        <ak tp="li">testing of backup restoration and disaster recovery</ak>
                        <ak tp="li">use made of post-incident learning</ak>
                        <ak tp="li">completeness of the critical asset and data registers</ak>
                    </narr>
                </narrative>
            </part>
        </part>
    </part>
    <part id="cases" v="01">
        <tyt>
            <tx l="en" nm="Cases"/>
        </tyt>
        <ctsy>
            <gr gn="area">
                <cts id="cybersecurity"/>
                <cts id="public-administration"/>
                <cts id="public-sector"/>
                <cts id="digitalisation"/>
                <cts id="computerisation"/>
                <cts id="internal-security"/>
                <cts id="financial-supervision"/>
                <cts id="social-security"/>
            </gr>
            <gr gn="ins">
                <cts id="central-government"/>
                <cts id="government-agency"/>
                <cts id="central-office"/>
                <cts id="public-service-provider"/>
                <cts id="supervisory-authority"/>
                <cts id="cybersecurity-authority"/>
                <cts id="audit-institution"/>
            </gr>
            <gr gn="control">
                <cts id="continuity"/>
                <cts id="disasterRecovery"/>
                <cts id="contingencyPlanning"/>
                <cts id="businessImpactAnalysis"/>
                <cts id="resilienceTerm"/>
                <cts id="incident_management"/>
                <cts id="incidentResponse"/>
                <cts id="rootCauseAnalysis"/>
                <cts id="monitoring"/>
                <cts id="activityTracking"/>
                <cts id="testing"/>
                <cts id="procedures"/>
                <cts id="documentation"/>
                <cts id="reporting"/>
                <cts id="responsibility"/>
                <cts id="accountabilityTerm"/>
                <cts id="guidance"/>
                <cts id="data"/>
                <cts id="dataSecurity"/>
                <cts id="feedbackTerm"/>
                <cts id="coordination"/>
            </gr>
            <gr gn="value">
                <cts id="regulatory_system"/>
                <cts id="asset"/>
                <cts id="human_capital"/>
                <cts id="domain_knowledge"/>
            </gr>
            <gr gn="fun">
                <cts id="security"/>
                <cts id="IT"/>
                <cts id="governance"/>
                <cts id="regulations"/>
                <cts id="planning"/>
                <cts id="productServiceDelivery"/>
                <cts id="structure"/>
            </gr>
            <gr gn="quality">
                <cts id="reliabilityAvailability"/>
                <cts id="soundRiskManagement"/>
                <cts id="functioningOversight"/>
                <cts id="reliableInformationBase"/>
                <cts id="clearObjectives"/>
                <cts id="streamlinedProcesses"/>
                <cts id="adequateResourcesCompetences"/>
            </gr>
            <gr gn="sta">
                <cts id="policy-setter"/>
                <cts id="oversight-role"/>
                <cts id="management"/>
                <cts id="operator"/>
                <cts id="staff"/>
                <cts id="supplier"/>
                <cts id="citizen"/>
                <cts id="beneficiary"/>
            </gr>
        </ctsy>
        <part id="backupsTakenDailyNever">
            <tyt>
                <tx l="en" nm="Backups are taken daily and have never been restored as a test"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="2" ref="draft draft" tp="xm" zn="AU2024cyberIncidents">The audit's overall conclusion turns on this one point: 'Neither entity is well placed to ensure business continuity or disaster recovery in the event of a significant or reportable cyber security incident' (p.9). Both run backups. Neither had established that they come back. At the first entity, 'AUSTRAC performs recovery of backups as part of business area requests. It does not perform testing of restoration of backups for disaster recovery purposes. It does not have a process for extracting and analysing production and archive backup data', and it 'has not tested the recoverability of its systems and applications supporting critical business processes' (p.50). At the second, the plans 'do not include all systems and applications supporting critical business processes and it does not test the recoverability of backups' (p.9), and the gap reaches the paperwork as well: 'Services Australia does not have a policy for managing regular backups', whose recovery documentation omits backup solutions from both the security policies and the disaster recovery testing schedule (p.84). A backup that has never been restored is a belief, not a control.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="continuity"/>
                    <cts id="disasterRecovery"/>
                    <cts id="testing"/>
                    <cts id="procedures"/>
                </gr>
                <gr gn="value">
                    <cts id="asset"/>
                </gr>
                <gr gn="fun">
                    <cts id="security"/>
                    <cts id="IT"/>
                </gr>
                <gr gn="quality">
                    <cts id="reliabilityAvailability"/>
                    <cts id="soundRiskManagement"/>
                </gr>
                <gr gn="sta">
                    <cts id="management"/>
                    <cts id="operator"/>
                </gr>
            </ctsy>
        </part>
        <part id="continuityPlanLeftSystems">
            <tyt>
                <tx l="en" nm="The continuity plan left out the systems the public actually depends on"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="3" ref="draft draft" tp="xm" zn="AU2024cyberIncidents">A recovery plan can only cover what someone has listed. 'The Business Continuity Plan outlines the recovery time objectives and maximum tolerable periods of disruption for a list of business processes. Services Australia does not have business continuity or disaster recovery plans that address all systems, including the systems which support the critical recovery processes. Services Australia does not have a complete list of critical assets. As such, Services Australia is not well placed to ensure business continuity or disaster recovery in the event of a significant or reportable cyber security incident' (p.84). What was missing was not marginal: 'Services Australia has a Disaster Recovery Testing Schedule dated 31 October 2023. This schedule did not include all the systems within Services Australia. This schedule was later updated by Services Australia to include three significant financial systems, Medicare, Payment Assessment Calculation Engine (PACE) and Child Support IT system (Cuba). This schedule update was the result of issues identified during the audit of Services Australia's 2023-24 financial statements' (p.84). The national health insurance scheme entered the recovery schedule because a different audit noticed it was absent.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="continuity"/>
                    <cts id="contingencyPlanning"/>
                    <cts id="businessImpactAnalysis"/>
                    <cts id="documentation"/>
                </gr>
                <gr gn="value">
                    <cts id="asset"/>
                </gr>
                <gr gn="fun">
                    <cts id="planning"/>
                    <cts id="productServiceDelivery"/>
                    <cts id="IT"/>
                </gr>
                <gr gn="quality">
                    <cts id="reliabilityAvailability"/>
                    <cts id="reliableInformationBase"/>
                </gr>
                <gr gn="sta">
                    <cts id="management"/>
                    <cts id="citizen"/>
                    <cts id="beneficiary"/>
                </gr>
            </ctsy>
        </part>
        <part id="alertsJudgedSignificantLeave">
            <tyt>
                <tx l="en" nm="Alerts judged not significant leave no written trace"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="4" ref="draft draft" tp="xm" zn="AU2024cyberIncidents">The entity's own plan sets the standard: its incident response plan 'states that "all information must be saved for future analysis preferably to a location not itself susceptible to [a security] incident"' (p.49). Practice stopped short of it. 'Only significant SIEM investigations are reported and logged in AUSTRAC's record-keeping repository where "significant" is defined by the security analyst. The SIEM investigation records include event logs, minutes and communications. Security alerts that have not been determined as "significant" are only reported verbally' (p.49). What was kept could not always be fetched back either: 'AUSTRAC could not provide archived SIEM data from 1 June 2022 to 31 October 2023. AUSTRAC does not have processes for extracting and retrieving cyber security events from either the production environment or archives for future analysis' (p.49). Seventeen months of the record, and the judgement of which events enter the record at all, rest on one analyst and on memory.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="documentation"/>
                    <cts id="data"/>
                    <cts id="dataSecurity"/>
                    <cts id="monitoring"/>
                    <cts id="activityTracking"/>
                </gr>
                <gr gn="value">
                    <cts id="domain_knowledge"/>
                </gr>
                <gr gn="fun">
                    <cts id="security"/>
                    <cts id="IT"/>
                </gr>
                <gr gn="quality">
                    <cts id="reliableInformationBase"/>
                    <cts id="functioningOversight"/>
                </gr>
                <gr gn="sta">
                    <cts id="operator"/>
                    <cts id="staff"/>
                    <cts id="oversight-role"/>
                </gr>
            </ctsy>
        </part>
        <part id="monitoringCoverageStayedBelow">
            <tyt>
                <tx l="en" nm="Monitoring coverage stayed below the standard because the effort went to prevention"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="5" ref="draft draft" tp="xm" zn="AU2024cyberIncidents">Detection was built on an arrangement nobody designed. 'The decentralised event logging approach was a result of historical management arrangements, where IT environments were managed by different AUSTRAC business areas and it has not been implemented in the recommended way. A centralised logging approach offers better control, efficiency and standardisation as recommended by the ASD's Guidelines for System Monitoring' (p.48). The reason given for leaving it there is the finding worth carrying: 'AUSTRAC has not implemented ASD's recommendation for appropriate SIEM coverage or documented a strategy for prioritising its event monitoring resources due to a "focus on implementing preventative controls to mitigate cyber security incidents"' (p.48). The summary states the consequence plainly - the 'coverage of event logs is not in accordance with ASD's Cyber Security Guidelines' and the entity 'does not have an event logging policy' (p.9). Spending on keeping attacks out is not a substitute for being able to see one that gets in.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="monitoring"/>
                    <cts id="activityTracking"/>
                    <cts id="guidance"/>
                    <cts id="procedures"/>
                    <cts id="coordination"/>
                </gr>
                <gr gn="value">
                    <cts id="regulatory_system"/>
                    <cts id="asset"/>
                </gr>
                <gr gn="fun">
                    <cts id="security"/>
                    <cts id="IT"/>
                    <cts id="structure"/>
                </gr>
                <gr gn="quality">
                    <cts id="streamlinedProcesses"/>
                    <cts id="soundRiskManagement"/>
                </gr>
                <gr gn="sta">
                    <cts id="management"/>
                    <cts id="policy-setter"/>
                </gr>
            </ctsy>
        </part>
        <part id="responseProcessClockAny">
            <tyt>
                <tx l="en" nm="A response process with no clock on any of its steps"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="6" ref="draft draft" tp="xm" zn="AU2024cyberIncidents">Both entities have the steps written down and neither has said how fast they must happen. For the first: it 'does not document cyber security incident meetings, nor has it defined timeframes for reporting to relevant stakeholders' (p.10), and it 'has not defined timeframes for analysing cyber security events, nor does it perform any analysis on the timeliness or completeness of triaging and escalation processes' (p.49). For the second: it 'has not established a timeframe for triage and escalation activities nor a process for analysing archived SIEM data' and 'has not defined an approach for cyber security investigations' (pp.9-10), and it 'has not defined the timeframes for reporting to relevant stakeholders' (p.11). The audit put a recommendation on each of these, and both entities agreed. In incident management the clock is the control: without a defined time to triage, escalate and report, there is nothing to measure performance against and nothing a reviewer can test.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="procedures"/>
                    <cts id="incident_management"/>
                    <cts id="incidentResponse"/>
                    <cts id="monitoring"/>
                    <cts id="reporting"/>
                </gr>
                <gr gn="value">
                    <cts id="regulatory_system"/>
                </gr>
                <gr gn="fun">
                    <cts id="security"/>
                    <cts id="governance"/>
                </gr>
                <gr gn="quality">
                    <cts id="clearObjectives"/>
                    <cts id="streamlinedProcesses"/>
                    <cts id="functioningOversight"/>
                </gr>
                <gr gn="sta">
                    <cts id="management"/>
                    <cts id="operator"/>
                    <cts id="oversight-role"/>
                </gr>
            </ctsy>
        </part>
        <part id="realBreachCameWent">
            <tyt>
                <tx l="en" nm="A real breach came and went without a lessons-learned review"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="7" ref="draft draft" tp="xm" zn="AU2024cyberIncidents">The learning is produced and then goes nowhere. At the first entity, 'AUSTRAC's incident reports include post-incident learning and post-remediation analysis. AUSTRAC undertook a root-cause analysis of the cyber security issue in 2023 which identified some systematic improvements. AUSTRAC does not use these incident reports to design and implement a security maturity monitoring plan or update its framework of procedures for cyber security incident management or share learnings internally and externally, where appropriate' (p.56). At the second the omission attaches to a named event: 'Any lessons learned from that experience, including support received from Services Australia's legal function, have not been used to review or update Services Australia's framework of procedures for cyber security incident management. Services Australia has not undertaken a post-incident review or a lessons-learned exercise following a large-scale data breach involving HWL Ebsworth Lawyers' (p.86). The audit's own message to every other entity is that post-incident learning 'greatly improves business continuity and recovery prospects' (p.17).</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="feedbackTerm"/>
                    <cts id="rootCauseAnalysis"/>
                    <cts id="incident_management"/>
                    <cts id="documentation"/>
                    <cts id="procedures"/>
                </gr>
                <gr gn="value">
                    <cts id="domain_knowledge"/>
                </gr>
                <gr gn="fun">
                    <cts id="security"/>
                    <cts id="governance"/>
                </gr>
                <gr gn="quality">
                    <cts id="soundRiskManagement"/>
                    <cts id="functioningOversight"/>
                </gr>
                <gr gn="sta">
                    <cts id="management"/>
                    <cts id="oversight-role"/>
                    <cts id="staff"/>
                </gr>
            </ctsy>
        </part>
        <part id="personEmpoweredDecideWritten">
            <tyt>
                <tx l="en" nm="The person empowered to decide has no written responsibilities"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="8" ref="draft draft" tp="xm" zn="AU2024cyberIncidents">Authority was granted and never described. The first entity 'has established management structures and responsibilities for managing cyber security incidents. However, it has not documented the assigned responsibilities for its CISO although the CISO is empowered to make decisions' (p.10), and the audit recommended it develop 'policies that define the responsibilities of the Chief Information Security Officer in accordance with the Protective Security Policy Framework requirements' (p.12). At the second the gap is one level higher: it 'does not have a policy covering the management of cyber security incidents' (p.9), and 'In January 2024, Services Australia advised the ANAO that it would commence developing the Cyber Security Incident Management and Response Policy from March 2024' (p.86) - that is, after the audit had begun. The report draws the general lesson for everyone else: entities should document policies and procedures, 'which is important for managing staff turnover', particularly where an organisation depends critically on a few key security advisors (p.17).</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="responsibility"/>
                    <cts id="accountabilityTerm"/>
                    <cts id="documentation"/>
                    <cts id="guidance"/>
                    <cts id="procedures"/>
                </gr>
                <gr gn="value">
                    <cts id="human_capital"/>
                    <cts id="regulatory_system"/>
                </gr>
                <gr gn="fun">
                    <cts id="governance"/>
                    <cts id="security"/>
                    <cts id="structure"/>
                </gr>
                <gr gn="quality">
                    <cts id="clearObjectives"/>
                    <cts id="adequateResourcesCompetences"/>
                </gr>
                <gr gn="sta">
                    <cts id="management"/>
                    <cts id="policy-setter"/>
                    <cts id="staff"/>
                </gr>
            </ctsy>
        </part>
        <part id="incidentResponseNeverBrings">
            <tyt>
                <tx l="en" nm="Incident response that never brings in the lawyers"/>
            </tyt>
            <narrative>
                <narr l="en">
                    <ak nr="9" ref="draft draft" tp="xm" zn="AU2024cyberIncidents">A serious incident is a legal event as much as a technical one, and neither response process treats it that way. At the first entity the reporting processes 'do not include the engagement of relevant expertise in other business areas, such as legal advisors, and do not ensure the integrity of evidence supporting cyber security investigations' (p.41). At the second, the programme built to catch the insider threat was assembled without that advice: its 'trusted insider program has not considered input from other business areas, such as its legal function' (p.60), and the same is true of the external reporting process, where the audit found no 'consideration of engaging other relevant expertise, such as legal advisors, during reporting processes' (p.60). The audit raises this to a message for all entities: as the regulatory landscape reforms, an entity should consider how its legal function 'will support their governance committees during the external reporting process to manage increasing scrutiny and liability risks' (p.17). Evidence that will not stand up is evidence collected for nothing.</ak>
                </narr>
            </narrative>
            <ctsy>
                <gr gn="control">
                    <cts id="coordination"/>
                    <cts id="incidentResponse"/>
                    <cts id="documentation"/>
                    <cts id="responsibility"/>
                </gr>
                <gr gn="value">
                    <cts id="regulatory_system"/>
                    <cts id="domain_knowledge"/>
                </gr>
                <gr gn="fun">
                    <cts id="governance"/>
                    <cts id="security"/>
                    <cts id="regulations"/>
                </gr>
                <gr gn="quality">
                    <cts id="soundRiskManagement"/>
                    <cts id="adequateResourcesCompetences"/>
                </gr>
                <gr gn="sta">
                    <cts id="management"/>
                    <cts id="oversight-role"/>
                    <cts id="policy-setter"/>
                </gr>
            </ctsy>
        </part>
    </part>
</dokAAPp>
