| 💼 1 Considerations for the Board | 3 | | | |
| 💼 7 This section sets out key information a Board could consider in relation to its responsibilities under CPS 234. The remainder of the PPG elaborates on this information, and contains additional detail on information security aimed at a broader audience. A Board member may find it beneficial to acquaint themselves with this additional detail as necessary. | | | | |
| 💼 8 Under CPS 234, the Board of an APRA-regulated entity is ultimately responsible for the information security of the entity. In order for a Board to be able to more effectively discharge its responsibilities (including oversight, seeking assurance and, as appropriate, challenging management), it could consider the following: | 6 | | | |
| 💼 8a roles and responsibilities — clearly outline for management how the Board expects to be engaged, including delegation of responsibilities, escalation of risks, issues and reporting requirements (including schedule, format, scope and content). Refer to Attachment H for common examples of the types of information that the Board might find useful to effectively fulfil its role and discharge its responsibilities. | | | | |
| 💼 8b information security capability — consider the sufficiency of the regulated entity’s information security capability in relation to vulnerabilities and threats; ensure sufficiency of investment to support the information security capability; and review progress with respect to execution of the information security strategy. | | | | |
| 💼 8c policy framework — whether information security policies reflect Board expectations. | | | | |
| 💼 8d implementation of controls — regularly seek assurance from and, as appropriate, challenge management on reporting regarding the effectiveness of the information security control environment and the overall health of the entity’s information assets. | | | | |
| 💼 8e testing control effectiveness — regularly seek assurance from and, as appropriate, challenge management on the sufficiency of testing coverage across the control environment; form a view as to the effectiveness of the information security controls based on the results of the testing conducted. | | | | |
| 💼 8f internal audit — consider the sufficiency of internal audit’s coverage, skills, capacity and capabilities with respect to the provision of independent assurance that information security is maintained; form a view as to the effectiveness of information security controls based on audit conclusions; and consider where further assurance, including through expert opinion or other means, is warranted. | | | | |
| 💼 9 In considering the above, the Board would normally take into account the use of third parties and related parties (including group functions) by the APRA-regulated entity. | | | | |
| 💼 2 Roles and responsibilities - Board delegations | 1 | | | |
| 💼 10 APRA does not seek to impose restrictions on a Board’s ability to delegate information security roles and responsibilities to Board sub-committees, management committees or individuals. However, APRA expects that a Board would clearly outline how it expects to be engaged with respect to information security, including escalation of risks, issues and reporting. Refer to Attachment H for common examples of the types of information that the Board might find useful in this regard. | | | | |
| 💼 3 Roles and responsibilities - Clearly defined roles and responsibilities | 2 | | | |
| 💼 11 Definition of information security-related roles and responsibilities is typically achieved through a combination of role statements, policy statements, reporting lines and charters of governing bodies. Common governing bodies and individuals with decision-making, approval, oversight, operations and other information security roles and responsibilities typically include: | 8 | | | |
| 💼 11a information security steering/oversight committee. | | | | |
| 💼 11b risk management committee (Board and management levels). | | | | |
| 💼 11c Board audit committee. | | | | |
| 💼 11d executive management/executive management committee. | | | | |
| 💼 11e chief information officer (CIO)/IT manager. | | | | |
| 💼 11f chief information security officer (CISO)/IT security manager. | | | | |
| 💼 11g information security operations/administration. | | | | |
| 💼 11h management (business and IT). | | | | |
| 💼 12 Information security roles and responsibilities are typically located in separate business areas, as well as within the IT function itself and in third parties and related parties. This can result in issues such as a lack of ownership, unclear accountabilities, ineffective oversight and fragmentation of practices with respect to information security. APRA regulated entities could address these issues by maintaining clear delineation between the responsibilities of each area and implementing compensating measures. Compensating measures could include establishing a virtual security group comprised of individuals with information security roles and responsibilities. | | | | |
| 💼 4 Roles and responsibilities - Sufficient and timely information | 2 | | | |
| 💼 13 The Board, governing bodies and individuals would typically define their information requirements (e.g. schedule, format, scope and content) to ensure they are provided with sufficient and timely information to effectively discharge their information security roles and responsibilities. Reporting to governing bodies would normally be supported by defined escalation paths and thresholds. An APRA-regulated entity could benefit from implementing processes for periodic review of audience relevance and fitness for use. | | | | |
| 💼 14 In APRA’s view, effective information security reporting normally incorporates both quantitative and qualitative content. For non-technical audiences, technical information and metrics would be supplemented with appropriate thematic analysis and commentary on business implications. Attachment H illustrates various information security reporting and metrics that governing bodies and individuals could find useful regarding information security. | | | | |
| 💼 5 Information security capability - Assessing sufficiency of capability | 2 | | | |
| 💼 15 In discharging its responsibility for information security, an APRA-regulated entity would typically assess the sufficiency of its information security capability. This could include reviewing the adequacy of resourcing, including funding and staffing, timely access to necessary skill sets and the comprehensiveness of the control environment — preventative, detective and responsive. | | | | |
| 💼 16 The current threat landscape has necessitated information security capabilities that extend beyond information technology general controls to more specialised information security capabilities. | 9 | | | |
| 💼 16a vulnerability and threat management; | | 11 | 11 | |
| 💼 16b situational awareness and intelligence; | | 6 | 7 | |
| 💼 16c information security operations and administration; | | 2 | 2 | |
| 💼 16d secure design, architecture and consultation; | | 1 | 1 | |
| 💼 16e security testing, including penetration testing; | | 10 | 10 | |
| 💼 16f information security reporting and analytics; | | 9 | 11 | |
| 💼 16g incident detection and response, including recovery, notification and communication; | | 2 | 2 | |
| 💼 16h information security investigation, including preservation of evidence and forensic analysis; | | | | |
| 💼 16i information security assurance. | | | | |
| 💼 6 Information security capability - Capability of third parties and related parties | 3 | | | |
| 💼 17 APRA-regulated entities often place reliance on information security capabilities of third parties and related parties to provide a targeted information security capability, or as part of a wider service-provision arrangement. Accordingly, entities would have a view as to the sufficiency of resources, skills and controls of third parties and related parties. This could be achieved through a combination of interviews, service reporting, control testing, certifications, attestations, referrals and independent assurance assessments. Any capability gaps identified would be addressed in a timely manner. | | | | |
| 💼 18 It is increasingly common for third parties to rely on other service providers to deliver an end-to-end service. This introduces additional vulnerabilities and threats. Under such circumstances, APRA’s expectation is that an APRA-regulated entity would take reasonable steps to satisfy itself that the third party has sufficient information security capability to manage the additional threats and vulnerabilities resulting from such arrangements. | | | | |
| 💼 19 An APRA-regulated entity could also consider the scope, depth and independence of certifications, attestations and assurance provided and take steps to address any limitations identified. | | | | |
| 💼 7 Information security capability - Adaptive and forward-looking investment | 1 | | | |
| 💼 20 Under CPS 234, an APRA-regulated entity must actively maintain an information security capability with respect to changes in vulnerabilities and threats. Accordingly, an entity would typically adopt an adaptive and forward-looking approach to maintaining its information security capability, including ongoing investment in resources, skills and controls. This would commonly be achieved through the execution of an information security strategy which responds to the changing environment throughout the year. The strategy could be informed by existing and emerging information security vulnerabilities and threats, contemporary industry practices, information security incidents, both internal and external, and known information security issues. Oversight of execution of the strategy is normally the responsibility of the Board or a delegated governing body with representation from across the organisation. | | | | |
| 💼 8 Policy framework - A policy hierarchy informed by a set of key principles | 2 | | | |
| 💼 21 An APRA-regulated entity’s information security policy framework is commonly structured as a hierarchy, with higher level policies supported by underlying standards, guidelines and procedures. A policy framework would normally be informed by a set of information security principles that guide decision-making with regard to information security (refer to Attachment A for common information security principles). | 11 | | | |
| 💼 21a identification, authorisation and granting of access to information assets (refer to Attachment C for further guidance); | | | | |
| 💼 21b life-cycle1 management that addresses the various stages of an information asset’s life to ensure that information security requirements are considered at each stage, from planning and acquisition through to decommissioning and destruction; | | | | |
| 💼 21c management of information security technology solutions that include firewall, antimalicious software, intrusion detection/prevention, cryptographic systems and monitoring/log analysis tools; | | | | |
| 💼 21d definition of an overarching information security architecture that outlines the approach for designing the IT environment (encompassing all information assets) from a security perspective (e.g. network zones/segments, end point controls, gateway design, authentication, identity management, interface controls, software engineering and location of information security technology solutions and controls); | | | | |
| 💼 21e monitoring and incident management to address the identification and classification of incidents, reporting and escalation guidelines, preservation of evidence and the investigation process; | | | | |
| 💼 21f expectations with respect to the maintenance of information security when using third parties and related parties; | | | | |
| 💼 21g acceptable usage of information assets that define the information security responsibilities of end-users including staff, third parties, related parties and customers (refer to Attachment B and Attachment F for further guidance); | | | | |
| 💼 21h recruitment and vetting of staff and contractors; | | | | |
| 💼 21i information security roles and responsibilities; | | | | |
| 💼 21j physical and environmental controls; | | | | |
| 💼 21k mechanisms to assess compliance with, and the ongoing effectiveness of, the information security policy framework. | | | | |
| 💼 22 An APRA-regulated entity’s information security policy framework would typically be consistent with other entity frameworks such as risk management, service provider management and project management. | | | | |
| 💼 9 Policy framework - Exemption handling | 2 | | | |
| 💼 23 An APRA-regulated entity could consider implementing processes that ensure compliance with its information security policy framework and regulatory requirements. This could include an exemption policy defining registration, authorisation and duration requirements. Exemptions are typically administered using a register detailing nature, rationale and expiry date. APRA envisages that an entity would review and assess the adequacy of compensating controls both initially and on an ongoing basis | | | | |
| 💼 24 Information assets that existed prior to an APRA-regulated entity’s current information security policy framework might not comply with the current framework’s requirements. In such instances, the regulated entity would typically raise an exemption and formulate a strategy for either replacing affected information assets or implementing appropriate compensating controls. | | | | |
| 💼 10 Policy framework - Ongoing effectiveness and completeness | 1 | | | |
| 💼 25 An APRA-regulated entity would typically periodically evaluate the effectiveness and completeness of its information security policy framework through a review of incidents that have occurred as well as comparisons to peers and established control frameworks and standards. Adjustments would be made to the policy framework to ensure its continued effectiveness. This assessment would typically also be conducted in response to a material change to information assets or the business environment. | | | | |
| 💼 11 Information asset identification and classification - Classification of all information assets by criticality and sensitivity | 3 | | | |
| 💼 26 A thorough understanding of an APRA-regulated entity’s information assets and the impact of a security compromise of those assets is important to maintain effective information security. | | | | |
| 💼 27 Under CPS 234, all information assets must be classified by criticality2 and sensitivity3 . This includes infrastructure, ancillary systems such as environmental control systems and physical access control systems as well as information assets managed by third parties and related parties. Furthermore, APRA-regulated entities could benefit from considering the interrelationships between information assets, including identifying information assets which are not intrinsically critical or sensitive but could be used to compromise information assets which are critical or sensitive. | | | | |
| 💼 28 In order to maintain the classification of its information assets, an APRA-regulated entity would benefit from implementing a process which identifies where the classification of information assets requires change as well as allowing for the classification of new information assets. This would normally be undertaken at least annually, or when there is a material change to the regulated entity’s information assets or business environment. | | | | |
| 💼 12 Information asset identification and classification - Classification methodology | 5 | | | |
| 💼 29 In order to identify and classify information assets, an APRA-regulated entity would benefit from maintaining a classification methodology that provides clarity as to what constitutes an information asset, granularity considerations and the method for rating criticality and sensitivity. The rating could take into account the impact of an information security compromise on an information asset. Notably, an information asset could be assessed as having a different rating from the perspective of its criticality and sensitivity. | | | | |
| 💼 30 APRA-regulated entities record information assets in various ways, sometimes at a very granular level and sometimes at an aggregated level. For example, a system can be seen as an aggregation of the underlying components (such as applications, databases, operating systems, middleware and data sets) and treated as a single information asset for classification purposes. Alternatively, a regulated entity could choose to treat each ofthe underlying components as individual information assets in their own right. Ultimately, the level of granularity would be sufficient to determine the nature and strength of controls required to protect the information asset. | | | | |
| 💼 31 In APRA’s view, where a regulated entity has chosen to aggregate a number of underlying components into a single information asset, the criticality and sensitivity ratings for that asset would typically inherit the criticality and sensitivity ratings of the constituent components with the highest ratings. | | | | |
| 💼 32 In order to facilitate information asset registration and mapping of interrelationships to other information assets, APRA-regulated entities typically use an information asset inventory repository such as a configuration management database (CMDB4 ). | | | | |
| 💼 33 It is common for APRA-regulated entities to leverage existing business continuity impact analyses to assess an information asset’s criticality. APRA-regulated entities would also typically maintain processes to systematically assess information asset sensitivity. | | | | |
| 💼 13 Implementation of controls - Information security controls implemented at all stages | 5 | | | |
| 💼 34 Under CPS 234, an APRA-regulated entity must have information security controls to protect its information assets commensurate with, amongst other things, the stage at which the information assets are within their life-cycle. This includes ensuring that information security controls remain effective at each stage of the life-cycle of the information asset and that there is formal allocation of responsibility and accountability for the information security of an information asset to an information asset owner. Typically, the information asset owner would be an individual located within the business function which is most dependent on the information asset | | | | |
| 💼 35 As the first phases of an information asset life-cycle, planning and design controls would typically be in place to ensure that information security is incorporated within the information assets of the APRA-regulated entity, the solutions implemented would typically comply with the information security requirements of an APRA-regulated entity as embodied in its information security policy framework. | | | | |
| 💼 36 Acquisition and implementation controls would typically be in place to ensure that information security is not compromised by the introduction of new information assets. Ongoing support and maintenance controls would typically be in place to ensure that information assets continue to meet the information security requirements of the APRAregulated entity | 13 | | | |
| 💼 36a change management —information security is addressed as part of the change management process and the information asset inventory is updated; | | 7 | 8 | |
| 💼 36b configuration management —the configuration of information assets minimises vulnerabilities and is defined, assessed, registered, maintained, including when new vulnerabilities and threats are discovered, and applied consistently; | | 1 | 1 | |
| 💼 36c deployment and environment management —development, test and production environments are appropriately segregated and enforce segregation of duties; | | 2 | 2 | |
| 💼 36d access management controls —only authorised users, software and hardware are able to access information assets (refer to Attachment B for further guidance); | | 13 | 13 | |
| 💼 36e hardware and software asset controls —appropriate authorisation to prevent security compromises from unauthorised hardware and software assets; | | 15 | 15 | |
| 💼 36f network design — to ensure authorised network traffic flows and to reduce the impact of security compromises; | | 28 | 29 | |
| 💼 36g vulnerability management controls — which identify and address information security vulnerabilities in a timely manner; | | 11 | 11 | |
| 💼 36h patch management controls — to manage the assessment and application of patches and other updates that address known vulnerabilities in a timely manner; | | 5 | 5 | |
| 💼 36i service level management mechanisms — to monitor, manage and align information security with business objectives; | | 2 | 2 | |
| 💼 36j monitoring controls — for timely detection of compromises to information security; | | 9 | 11 | |
| 💼 36k response controls — to manage information security incidents and feedback mechanisms to address control deficiencies; | | 10 | 10 | |
| 💼 36l capacity and performance management controls — to ensure that availability is not compromised by current or projected business volumes; | | | | |
| 💼 36m service provider management controls — to ensure that a regulated entity’s information security requirements are met. | | | | |
| 💼 37 Decommissioning and destruction controls are typically used to ensure that information security is not compromised as information assets reach the end of their useful life. Examples include archiving strategies and the secure data deletion (that is, deleting data using techniques to ensure data is irrecoverable) of sensitive information prior to the disposal of information assets. | | | | |
| 💼 38 An APRA-regulated entity could find it useful to regularly assess the completeness of its information security controls by comparison to peers and contemporary industry practices. | | | | |
| 💼 14 Implementation of controls - Vulnerabilities and threats are identified, assessed and remediated | 1 | | | |
| 💼 39 An APRA-regulated entity would typically ensure that existing and emerging information security vulnerabilities and threats pertaining to critical and sensitive information assets are identified, assessed and remediated in a timely manner. This includes information assets which are not critical or sensitive but could expose those information assets that are critical or sensitive. | 4 | | | |
| 💼 39a implement mechanisms that access and analyse timely threat intelligence regarding vulnerabilities, threats, methods of attack and countermeasures; | | 11 | 11 | |
| 💼 39b engage with stakeholders (including Government, industry participants and customers) regarding threats and countermeasures, as appropriate | | | | |
| 💼 39c develop tactical and strategic remediation activities for the control environment (prevention, detection and response) commensurate with the threat; | | | | |
| 💼 39d implement mechanisms to disrupt the various phases of an attack. Example phases include reconnaissance, vulnerability exploitation, malware installation, privilege escalation, and unauthorised access | | 11 | 11 | |
| 💼 15 Implementation of controls - End-of-life and out-of-support issues | 4 | | | |
| 💼 40 An important aspect of information asset life-cycle management involves minimising vulnerabilities and maintaining support. Information security exposures could arise from hardware and software which is outdated or has limited or no support (whether through a third party, a related party or in-house). Technology that is end-of-life5 , out-of-support or in extended support is typically less secure by design, has a dated security model and can take longer, or is unable, to be updated to address new threats. | | 5 | 5 | |
| 💼 41 Maintaining information assets therefore necessitates a disciplined approach to information asset life-cycle management, including a comprehensive understanding of assets that support the business, as well as the potential impacts of an information security compromise of these assets. Maintenance of information assets can be facilitated through the monitoring of end-of-support dates, where available, and the active identification of systems, including those that are internally-developed and which are no longer invested in or are not secure by design. A technology refresh plan with committed resourcing can also facilitate the timely replacement of hardware and software. | | | | |
| 💼 42 Where extended support arrangements are in place, it is important that there is a clear understanding of the nature and effectiveness of these arrangements. Additionally, while extended or custom support arrangements may partially mitigate risk, they are often costly, could provide a false sense of security and can further delay remediation of ageing technology. Furthermore, support agreements of this nature typically provide hot-fixes or patches for critical vulnerabilities only, and remain constrained by the dated security model and design limitations of the technology. | | | | |
| 💼 43 To minimise information security vulnerabilities, an APRA-regulated entity would typically decommission systems: a. that cannot be adequately updated as new security vulnerabilities or threats are identified; b. where the use of mitigating controls — such as segregation from other information assets — is not an option. | | | | |
| 💼 16 Implementation of controls - Minimise exposure to plausible worst case scenarios | 2 | | | |
| 💼 44 APRA-regulated entities could consider low likelihood scenarios, which could result in an extreme impact to the regulated entity (i.e. plausible worst case). Extreme impacts can be financial or non-financial (e.g. reputational or regulatory), potentially threatening the ongoing ability of the APRA-regulated entity to meet its obligations. | 3 | | | |
| 💼 44a malicious acts by an insider with highly-privileged access, potentially involving collusion with internal or external parties; | | 1 | 1 | |
| 💼 44b deletion or corruption of both production and backup data, either through malicious intent, user error or system malfunction; | | 6 | 7 | |
| 💼 44c loss of, or unauthorised access to, encryption keys safeguarding extremely critical or sensitive information assets. | | 8 | 10 | |
| 💼 45 An understanding of plausible worst case scenarios can help regulated entities identify and implement additional controls to prevent or reduce the impact of such scenarios. One example is malware that infects computers and encrypts data, both on the infected computer and any connected storage, including (corporate) networks and cloud storage. Such attacks reinforce the importance of protecting the backup environment in the event that the production environment is compromised. Common techniques to achieve this include network segmentation, highly restricted and segregated access controls and network traffic flow restrictions. | | 34 | 36 | |
| 💼 17 Implementation of controls - Physical and environmental controls | 1 | | | |
| 💼 46 The absence of physical and environmental controls can compromise the effectiveness of other information security controls. An APRA-regulated entity would typically have in place the following physical and environmental controls (commonly through professionally managed data centres as part of third party or related party arrangements): | 4 | | | |
| 💼 46a location and building facilities that provide a level of protection from natural and man-made threats. This includes diversity of access to key utility services such as power and telecommunications, as well as fall-back mechanisms where access to the key utility service has failed (e.g. generators, Uninterrupted Power Supply (UPS) devices and alternate telecommunication connections); | | | | |
| 💼 46b physical access controls that protect the site perimeter, building, data room and computing racks. Common controls include gates, locks and procedures for granting and reviewing access by staff, third party providers and visitors; | | | | |
| 💼 46c environmental controls which maintain environmental conditions within acceptable parameters. Common controls include ventilation, air conditioning and fire suppressant systems; | | | | |
| 💼 46d monitoring and alert mechanisms that detect information security incidents where physical and environmental controls have failed. Common controls include sensors/alarms for temperature, humidity, water, smoke, unauthorised access; and service availability alerts (e.g. power supply, telecommunication, servers). | | | | |
| 💼 18 Implementation of controls - Security in change management | 1 | | | |
| 💼 47 APRA envisages that a regulated entity would implement controls to manage changes to information assets, including changes to hardware, software, data, and configuration (both where the change is planned and in response to an emergency) with the aim of maintaining information security. | 7 | | | |
| 💼 47a security testing (including reviews) to identify vulnerabilities and confirm information security requirements have been met. The nature of testing would be commensurate with the scope of the change and the sensitivity and criticality of the impacted information asset (refer to Attachment H for examples of common testing techniques); | | | | |
| 💼 47b approval of changes prior to deployment into the production environment; | | | | |
| 💼 47c segregation of duty controls which prevent personnel from deploying their own software changes to production; | | 5 | 5 | |
| 💼 47d changes are developed and verified in another environment, sufficiently segregated from production so as to avoid any compromise of information security; | | | | |
| 💼 47e information security requirements are validated prior to deployment; | | | | |
| 💼 47f desensitising sensitive production data when used for development or testing purposes; | | | | |
| 💼 47g intentionally introduced information security vulnerabilities are authorised. In APRA’s view, changes that knowingly introduce security vulnerabilities would be minimised and, where possible, compensating controls implemented. This situation normally arises when dealing with system outages. | | | | |
| 💼 19 Implementation of controls - Software security | 2 | | | |
| 💼 48 An APRA-regulated entity would typically implement secure software development and acquisition techniques to assist in maintaining confidentiality, integrity and availability by improving the general quality and vulnerability profile of the software (refer to Attachment D for further guidance). | | | | |
| 💼 49 The outcome of secure software development and acquisition is to ensure that software: | 3 | | | |
| 💼 49a continues to function as intended regardless of unforeseen circumstances, including where erroneous input is supplied; | | | | |
| 💼 49b has a reduced propensity to be misused either intentionally (e.g. for the purposes of theft) or inadvertently; | | | | |
| 💼 49c complies with the information security policy framework. | | | | |
| 💼 20 Implementation of controls - Data leakage | 4 | | | |
| 💼 50 Data leakage is the unauthorised removal, copying, distribution, capturing or other types of disclosure of sensitive data that results in a loss of data confidentiality (also known as a data breach). Access to data removal methods would typically be subject to risk assessment and only granted where a valid business need exists. | | | | |
| 💼 51 Controls, commensurate with the sensitivity and criticality of the data, would typically be implemented where sensitive data is at risk of leakage. Examples of data leakage methods include the misuse of portable computing devices (e.g. laptops, tablets, mobile phones), portable storage devices (e.g. USB flash drives, portable hard drives, writable disks), electronic transfer mechanisms (e.g. email, instant messaging) and hard copy. | | | | |
| 💼 52 Typically, the strength of data leakage controls would be commensurate with the sensitivity of the data. | 6 | | | |
| 💼 52a authorisation, registration and regular review of users and associated transfer mechanisms and devices, including printers, telephony and video conferencing equipment. Users with a greater level of access to sensitive data would be subject to increased scrutiny; | | | | |
| 💼 52b appropriate blocking, filtering and monitoring of electronic transfer mechanisms, websites and printing; | | | | |
| 💼 52c appropriate encryption, cleansing and auditing of devices; | | 9 | 9 | |
| 💼 52d appropriate segmentation of data, based on sensitivity and access needs; | | 10 | 10 | |
| 💼 52e monitoring for unauthorised software and hardware (e.g. key loggers, password cracking software, wireless access points, business implemented technology solutions); | | 10 | 10 | |
| 💼 52f appropriate removal of sensitive data after recovery tests are concluded. | | | | |
| 💼 53 Wholesale access to sensitive data (e.g. contents of customer databases or intellectual property that can be exploited for personal gain) would be highly restricted to reduce the risk exposure to significant data leakage events. Industry experience of actual data leakage incidents include the unauthorised extraction of debit/credit card details, theft of personally identifiable information, loss of unencrypted backup media and the sale/trade or exploitation of customer identity data. | | 10 | 10 | |
| 💼 21 Implementation of controls - Cryptographic techniques to restrict access | 2 | | | |
| 💼 54 Cryptographic techniques can be used to control access to sensitive data, both in storage and in transit. The strength of the cryptographic techniques deployed would be commensurate with the sensitivity and criticality of the data as well as other supplementary or compensating controls (refer to Attachment E for further guidance). | | 17 | 18 | |
| 💼 55 In order to minimise the risk of compromise, an end-to-end approach would typically be adopted, where encryption is applied from the point-of-entry to final destination. | | 1 | 1 | |
| 💼 22 Implementation of controls - Information security technology solutions | 1 | | | |
| 💼 56 An APRA-regulated entity would typically deploy appropriate information security technology solutions which maintain the security of information assets. Examples include firewalls, network access control, intrusion detection/prevention devices, anti-malware, encryption and monitoring/log analysis tools. The degree of reliance placed on technology solutions for information security could necessitate a heightened set of lifecycle controls, including but not limited to: | 6 | | | |
| 💼 56a guidelines outlining when information security-specific technology solutions should be used; | | | | |
| 💼 56b standards documenting the detailed objectives and requirements of individual information security-specific technology solutions; | | | | |
| 💼 56c authorisation of individuals who can make changes to information security-specific technology solutions. This would typically take into account segregation of duties issues; | | | | |
| 💼 56d regular assessment of the information security-specific technology solutions configuration, assessing both continued effectiveness as well as identification of any unauthorised access or modification; | | | | |
| 💼 56e periodic review of industry practice and benchmarking against peers; | | | | |
| 💼 56f detection techniques deployed which provide an alert if information security-specific technology solutions are not working as designed. | | | | |
| 💼 23 Implementation of controls - End-user developed/configured software | 3 | | | |
| 💼 57 Current technologies allow end-users to develop/configure software for the purpose of automating day-to-day business processes or facilitating decision-making (e.g. spreadsheets, local databases, user administered software). This creates the risk that life-cycle controls could be inadequate for critical information assets and possibly lead to a proliferation of sensitive data being accessible outside controlled environments. | | | | |
| 💼 58 An APRA-regulated entity would typically introduce processes to identify and classify end-user developed/configured software and assess risk exposures. In APRA’s view, any information software asset that is critical to achieving the objectives of the business or that processes sensitive data would comply with the relevant life-cycle management controls of the regulated entity. | | | | |
| 💼 59 Sound practice is to establish a formal policy to govern end-user developed/configured software. The policy would clearly articulate under what circumstances end-user developed/configured software is appropriate, as well as expectations regarding lifecycle management controls including information security, development, change management and backup. | | | | |
| 💼 24 Implementation of controls - Emerging technologies | 3 | | | |
| 💼 60 New technologies potentially introduce a set of additional information security vulnerabilities, both known and unknown. An APRA-regulated entity would typically apply appropriate caution when considering the introduction of new technologies. | | | | |
| 💼 61 Typically, an APRA-regulated entity would only authorise the use of new technologies in a production environment where the technology: | 2 | | | |
| 💼 61a has matured to a state where there is a generally agreed set of industry-accepted controls to manage the security of the technology; | | | | |
| 💼 61b compensating controls are sufficient to reduce residual risk within the entity’s risk appetite. | | | | |
| 💼 62 An APRA-regulated entity could find it useful to develop a technology authorisation process and maintain an ‘approved technology register’ to facilitate this. The authorisation process would typically assess the benefits of the new technology against the impact of an information security compromise, including an allowance for uncertainty. | | | | |
| 💼 25 Implementation of controls - Information assets managed by third parties and related parties | 3 | | | |
| 💼 63 Evaluation of the design of information security controls of third parties and related parties necessitates an understanding of the controls in place or planned. This can be maintained over time through a combination of interviews, surveys, control testing, certifications, contractual reviews, attestations and independent assurance assessments. Controls identified can then be compared to common industry controls and considered in light of controls within the regulated entity as well as the nature of the information assets involved. Any capability gaps identified would be addressed in a timely manner. | | | | |
| 💼 64 Third parties and related party agreements often take advantage of sub-contracting/onsourcing arrangements, whether at the start of the arrangement or over time. Consequently, in order to effectively evaluate the design of information security controls, an APRA-regulated entity would consider what is permissible within the agreement, and ongoing awareness of changes to the way services are provided. | | | | |
| 💼 65 An APRA-regulated institution would usually consider whether information security considerations are appropriately captured in contractual obligations and oversight arrangements. The regulated entity would also consider the scope, depth and independence of any certifications, attestations and assurance provided and take steps to address any limitations identified. | | | | |
| 💼 26 Incident management - Detection of security compromises | 4 | | | |
| 💼 66 Under CPS 234, an APRA-regulated entity is required to have robust mechanisms in place to detect and respond to actual or potential compromises of information security in a timely manner. The term ‘potential’ is used to highlight that information security incidents are commonly identified when an event occurs (e.g. unauthorised access notification, customer complaint) requiring further investigation in order to ascertain whether an actual security compromise has occurred. | | 10 | 10 | |
| 💼 67 Detection mechanisms typically include scanning, sensing and logging mechanisms which can be used to identify potential information security incidents. Monitoring processes could include the identification of unusual patterns of behaviour and logging that facilitates investigation and preserves forensic evidence. The strength and nature of monitoring controls would typically be commensurate with the impact of an information security incident. Monitoring processes would consider the broad set of events, ranging from the physical hardware layer to higher order business activities such as payments and changes to user access. | 5 | | | |
| 💼 67a network and user profiling that establishes a baseline of normal activity which, when combined with logging and alerting mechanisms, can enable detection of anomalous activity; | | 18 | 21 | |
| 💼 67b scanning for unauthorised hardware, software and changes to configurations; | | 7 | 8 | |
| 💼 67c sensors that provide an alert when a measure breaches a defined threshold(s) (e.g. device, server and network activity); | | 10 | 10 | |
| 💼 67d logging and alerting of access to sensitive data or unsuccessful logon attempts to identify potential unauthorised access; | | 1 | 1 | |
| 💼 67e users with privileged access accounts subject to a greater level of monitoring in light of the heightened risks involved. | | 1 | 1 | |
| 💼 68 Monitoring processes and tools remain in step with the evolving nature of threats and contemporary industry practices. | | 10 | 10 | |
| 💼 69 APRA envisages that a regulated entity would establish a clear allocation of responsibilities for monitoring processes, with appropriate tools in place to enable timely detection. Access controls and segregation of duties would typically be used as a means to safeguard the integrity of the monitoring processes. | | | | |
| 💼 27 Incident management - Information security incident stages | 1 | | | |
| 💼 73 Under CPS 234, an APRA-regulated entity’s information security response plans must include mechanisms for managing all relevant stages of an incident. | 7 | | | |
| 💼 73a detection of an information security event through the use of automated sensors and manual review; | | 10 | 10 | |
| 💼 73b identification and analysis to determine if it is an incident or an event; | | 10 | 10 | |
| 💼 73c escalation to ensure that decision-makers are aware of the incident and to trigger incident response processes; | | 2 | 2 | |
| 💼 73d containment to minimise the damage caused, and reduce the possibility of further damage; | | 10 | 10 | |
| 💼 73e eradication which involves the removal of the source of the information security compromise (typically malware); | | 10 | 10 | |
| 💼 73f response and recovery which involves a mixture of system restoration (where integrity and availability have been compromised) and managing sensitive data loss where confidentiality has been compromised. This allows for a return to businessas-usual processing; | | 4 | 4 | |
| 💼 73g post-incident analysis and review to reduce the possibility of a similar information security incident in the future, improve incident management procedures and forensic analysis to facilitate attribution and restitution (where relevant). | | | | |
| 💼 28 Incident management - Incident response testing | 1 | | | |
| 💼 74 Under CPS 234, an APRA-regulated entity must annually review and test its information security response plans to ensure they remain effective and fit-for-purpose. It is important that the success criteria for such tests are clearly defined, including the circumstances under which re-testing would be required. Test results could be reported to the appropriate governing body or individual, with associated follow-up actions formally tracked and reported. | | | | |
| 💼 29 Incident management - Third parties and related parties | 2 | | | |
| 💼 75 In APRA’s view, a regulated entity would benefit from agreeing each party’s roles and responsibilities where incident response requires collaboration and coordination between the regulated entity and third parties or related parties. This could involve formalisation of points of integration between third party and related party incident response plans and involvement of third parties and related parties in incident response testing. | | | | |
| 💼 76 APRA-regulated entities that place reliance on the information security capabilities of third parties and related parties as part of a broader service provision arrangement would typically seek evidence of the periodic testing of incident response plans by those parties. | | | | |
| 💼 30 Incident management - Integration with business continuity and crisis management | 1 | | | |
| 💼 77 In APRA’s view, a regulated entity would benefit from clear linkages between information security response plans and business continuity processes, including crisis management, continuity plans and recovery plans. This could involve integration with third party and related party plans and processes. | | | | |
| 💼 31 Testing control effectiveness - Systematic testing program | 4 | | | |
| 💼 78 In order to systematically test information security controls, an APRA-regulated entity would normally outline the population of information security controls across the regulated entity, including any group of which it is a part, and maintain a program of testing which validates the design and operating effectiveness of controls over time. Additional testing could be triggered by changes to vulnerabilities/threats, information assets or the threat landscape | | | | |
| 💼 79 In APRA’s view, the frequency and scope of testing would ensure that a sufficient set of information security controls are tested, at least annually, in order to validate that information security controls remain effective. Furthermore, controls protecting information assets exposed to ‘untrusted’ environments7 would typically be tested throughout the year. | | | | |
| 💼 80 The nature of testing would be a function of the type of control, and would typically consider a variety of testing approaches informed by contemporary industry practices (refer to Attachment G for further guidance). | | | | |
| 💼 81 It is important that success criteria for tests are clearly defined, including the circumstances under which re-testing would be required. Test results would be reported to the appropriate governing body or individual, with associated follow-up actions formally tracked and reported. | | | | |
| 💼 32 Testing control effectiveness - Independence of testers | 1 | | | |
| 💼 82 Under CPS 234, an APRA-regulated entity must ensure that testing is conducted by appropriately skilled and functionally independent specialists. For an APRA-regulated entity to have confidence in the quality of testing, it is important that testers are sufficiently independent in order to provide a bias-free assessment of controls (i.e. unimpeded by a conflict of interest). This includes the use of testers who do not have operational responsibility for the controls being validated. The level of functional independence required would typically be determined by the nature and importance of the testing. | | | | |
| 💼 33 Internal audit - Assurance to the Board | 3 | | | |
| 💼 83 Internal audit is an important vehicle by which the Board can gain assurance that information security is maintained. This assurance would typically be achieved through the inclusion of information security within the APRA-regulated entity’s internal audit plan. The Board could also choose to gain assurance through expert opinion or other means to complement the assurance provided by the internal audit function. This typically occurs where the required skills do not reside within the internal audit function or the area subject to audit pertains to third parties or related parties. | | | | |
| 💼 84 Under CPS 234, an APRA-regulated entity’s internal audit function must review the design and operating effectiveness of information security controls. In APRA’s view, an approach which achieves comprehensive assurance would involve an audit program which assesses all aspects of the information security control environment over time. The frequency at which areas to be audited are assessed would take into account the impact of an information security compromise and the ability to place reliance on other control testing undertaken. Additional assurance work may be triggered by changes to vulnerabilities and threats or material changes to IT assets. | | | | |
| 💼 85 Where internal audit relies on control testing performed by other areas, APRA would expect the internal audit function to assess the scope and quality of the testing conducted in order to determine how much reliance can be placed upon it. | | | | |
| 💼 34 Internal audit - Use of assurance reports from third parties | 1 | | | |
| 💼 86 Under CPS 234, an APRA-regulated entity’s internal audit function must assess the information security control assurance provided by a third party or related party in certain circumstances. Where that assessment identifies material deficiencies in the information security control assurance provided by the third party or related party, or no assurance is available, this would typically be highlighted in reporting to the Board. | | | | |
| 💼 Attachment A - Security principles | 1 | | | |
| 💼 1 APRA envisages that an APRA-regulated entity would adopt a set of high-level information security principles in order to establish a sound foundation for the entity’s information security policy framework. Common information security principles include: | 10 | | | |
| 💼 a. implement multiple layers and types of controls such that if one control fails, other controls limit the impact of an information security compromise. This is typically referred to as the principle of ‘defence in depth’; | | | | |
| 💼 b. access to, and configuration of, information assets is restricted to the minimum required to achieve business objectives. This is typically referred to as the principle of ‘least privilege’ and aims to reduce the number of attack vectors that can be used to compromise information security; | | 3 | 3 | |
| 💼 c. Timely detection of information security incidents. This minimises the impact of an information security compromise; | | | | |
| 💼 d. information security is incorporated into the design of the information system asset. This is typically referred to as secure by design; | | | | |
| 💼 e. use of, and access to, information assets is attributable to an individual, hardware or software, and activity logged and monitored; | | 2 | 2 | |
| 💼 f. error handling is designed such that errors do not allow unauthorised access to information assets or other information security compromises; | | | | |
| 💼 g. assume information assets have an unknown and possibly reduced level of information security control. This is typically referred to as the principle of ‘never trust, always identify’; | | | | |
| 💼 h. segregation of duties is enforced through appropriate allocation of roles and responsibilities. This reduces the potential for the actions of a single individual to compromise information security; | | 3 | 3 | |
| 💼 i. design controls that enforce compliance with the information security policy framework, thereby reducing reliance on individuals; | | | | |
| 💼 j. design detection and response controls based on the assumption that preventive controls have failed. This is typically referred as the principle of ‘assumed breach’. | | | | |
| 💼 Attachment B - Training and awareness | 3 | | | |
| 💼 1 An APRA-regulated entity could benefit from developing a training and information security awareness program. This would typically communicate to personnel (staff, contractors and third parties) regarding information security practices, policies and other expectations as well as providing material to assist the Board and other governing bodies to execute their duties. Sound practice would involve tracking training undertaken and testing the understanding of relevant information security policies, both on commencement and periodically. | | | | |
| 💼 2 An APRA-regulated entity would regularly educate users, including both internal staff and contractors, as to their responsibilities regarding securing information assets. Common areas covered would typically include: | 9 | | | |
| 💼 a. personal versus corporate use of information assets; | | | | |
| 💼 b. email usage, internet usage (including social networking) and malwareprotection; | | | | |
| 💼 c. physical protection, remote computing and usage of mobile devices; | | | | |
| 💼 d. awareness of common attack techniques targeted at personnel and facilities (e.g. social engineering, tailgating); | | | | |
| 💼 e. access controls, including standards relating to passwords and other authentication requirements; | | | | |
| 💼 f. responsibilities with respect to any end-user developed/configured software (including spreadsheets, databases and office automation); | | | | |
| 💼 g. expectations of staff where bring-your-own-device is an option; | | | | |
| 💼 h. handling of sensitive data; | | | | |
| 💼 i. reporting of information security incidents and concerns. | | | | |
| 💼 3 An APRA-regulated entity would typically require users to adhere to appropriate information security policies pertinent to their roles and responsibilities. At a minimum, all users would typically be required to periodically sign-off on these policies as part of the terms and conditions of their employment or contractual agreements. | | | | |
| 💼 Attachment C - Identity and access | 8 | | | |
| 💼 1 Identity and access management controls would ideally ensure access to information assets is only granted where a valid business need exists, and only for as long as access is required. Access is typically granted to users, special purpose system accounts, and information assets such as services and other software. | | 3 | 3 | |
| 💼 2 Factors to consider when authorising access to information assets include: business role, physical location, remote access, time and duration of access, patch and antimalware status, software, operating system, device and method of connectivity. | | | | |
| 💼 3 The provision of access involves the following process stages: | 3 | | | |
| 💼 a. identification — determination of who or what is requesting access; | | | | |
| 💼 b. authentication — confirmation of the purported identity; | | | | |
| 💼 c. authorisation — assessment of whether access is allowed to an information asset by the requestor based on the needs of the business and the level of information security (trust) required. | | | | |
| 💼 4 Regulated entities would typically put in place processes to ensure that identities and credentials are issued, managed, verified, revoked and audited for authorised devices, users and software/processes. | | 8 | 8 | |
| 💼 5 The strength of identification and authentication would typically be commensurate with the impact should an identity be falsified. Common techniques for increasing the strength of identification and authentication include the use of strong password techniques (i.e. length, complexity, re-use limitations and frequency of change), utilisation of cryptographic techniques and increasing the number and type of authentication factors used. Authentication factors include something an individual: a. knows - for example, user IDs and passwords; b. has - for example, a security token or other devices in the person’s possession used for the generation of one-time passwords; c. is - for example, retinal scans, hand scans, signature scans, digital signature, voice scans or other biometrics. | | 3 | 3 | |
| 💼 6 The following are examples where increased authentication strength is typically required, given the impact should an identity be falsified: a. administration or other privileged access to sensitive or critical information assets; b. remote access (i.e. via public networks) to sensitive or critical information assets; c. high-risk activities (e.g. third-party fund transfers, creation of new payees) | | 2 | 2 | |
| 💼 7 A regulated entity would typically deploy the following access controls: | 12 | | | |
| 💼 a. undertake due diligence processes before granting access to personnel. The use of contractors and temporary staffing arrangements may elevate the risk for certain roles; | | | | |
| 💼 b. implementation of role-based access profiles which are designed to ensure effective segregation of duties; | | | | |
| 💼 c. prohibiting sharing of accounts and passwords (with the possible exception of generic accounts, where prohibiting sharing of accounts and passwords is unavoidable due to technology constraints); | | 1 | 1 | |
| 💼 d. changing default passwords and user names | | | | |
| 💼 e. timely removal of access rights whenever there is a change in role or responsibility and on cessation of employment; | | | | |
| 💼 f. session timeouts; | | | | |
| 💼 g. processes to notify appropriate personnel of user additions, deletions and role changes; | | | | |
| 💼 h. audit logging and monitoring of access to information assets by all users; | | 7 | 8 | |
| 💼 i. regular reviews of user access by information asset owners to ensure appropriate access is maintained; | | | | |
| 💼 j. multi-factor authentication for privileged access, remote access and other high-risk activities; | | 2 | 2 | |
| 💼 k. generation, in preference to storage, of passwords/Personal Identification Numbers (PINs) where used to authorise high-risk activities (e.g. debit/credit card and internet banking transactions); | | | | |
| 💼 l. two-person rule applied to information assets with the APRA-regulated entity’s highest level of sensitivity rating (e.g. encryption keys, PIN generation, debit/credit card databases). | | | | |
| 💼 8 For accountability purposes, a regulated entity would typically ensure that users and information assets are uniquely identified and their actions are logged at a sufficient level of granularity to support information security monitoring processes. | | 2 | 2 | |
| 💼 Attachment D - Software security | 4 | | | |
| 💼 1 APRA envisages that a regulated entity would formally include information security considerations throughout the software delivery life-cycle, including where agile techniques are used. Typical software delivery life-cycle activities comprise ascertaining requirements, selection and configuration (for vendor provided software, including Software as a Service8 ), design and programming (for in-house developed software), testing and implementation | | | | |
| 💼 2 Ongoing security of existing software would also typically be considered as part of change management and as new vulnerabilities are identified. Typical factors to consider include: | 4 | | | |
| 💼 a. requirements — information security requirements would be explicitly identified as part of the requirements definition of the software and address potential threats; | | | | |
| 💼 b. design — considerations when designing secure software could include software modularisation; where on the network the software is located; what privileges the software executes under; inclusion of information security features as part of the technical specifications; and the information security standards and guidelines the software specifications are written to; | | | | |
| 💼 c. selection and configuration — considerations when selecting and configuring vendor supplied software include due diligence as to the security testing conducted to identify vulnerabilities (either intended or deliberate); user access management capabilities (e.g. role based, support of segregation of duties); interface vulnerabilities; monitoring capabilities; encryption capabilities to protect sensitive data; ability to obtain and implement information security updates in a timely manner; compliance with the security policy framework; and configuration/implementation of the software which minimises the risk of a security compromise; | | | | |
| 💼 d. standards and guidelines — the body of knowledge for developing secure software would typically be embodied in a set of standards and guidelines. Typically, standards would exist for each programming language, taking into account known vulnerabilities and what is considered to be good practice. It is important that standards remain aligned with industry developments such as emerging vulnerabilities/threats and associated compensating controls. In developing software standards and guidelines, consideration would typically be given to: | 4 | | | |
| 💼 i. common software requirements such as authentication, authorisation, session management, data validation, cryptography, logging, configuration, auditing, deployment and maintenance; | | | | |
| 💼 ii. techniques for addressing common weaknesses such as poor exception and error handling; weak file and group permissions; use and storage of temporary files; unnecessary code; insecure system calls; poor password handling; and susceptibility to buffer overflow, code insertion and resource (e.g. memory) leakage; | | | | |
| 💼 iii. software defence techniques against known vulnerabilities; | | | | |
| 💼 iv. approaches for secure input/output handling. | | | | |
| 💼 3 An APRA-regulated entity could find it useful to maintain a register of approved software development tools and associated usage. The regulated entity would typically enforce compliance with the register for the purposes of quality control, avoiding compromises of the production environment and reducing the risk of introducing unexpected vulnerabilities. This would not preclude the use of other tools in a non-production environment for the purposes of evaluation and experimentation. | | | | |
| 💼 4 An APRA-regulated entity would typically implement roles, responsibilities and tools for managing the registration and deployment of source code to ensure that information security requirements are not compromised. | | | | |
| 💼 Attachment E - Cryptographic techniques | 5 | | | |
| 💼 1 Cryptographic techniques refer to methods used to encrypt data, confirm its authenticity or verify its integrity. The following are examples where APRA-regulated entities could deploy cryptographic techniques given the risks involved: | 4 | | | |
| 💼 a. transmission and storage of critical and/or sensitive data in an ‘untrusted’ environment or where a higher degree of security is required; | | | | |
| 💼 b. detection of any unauthorised alteration of data; | | | | |
| 💼 c. verification of the authenticity of transactions or data; | | | | |
| 💼 d. protection of customer PINs which are typically used for debit/credit cards and online services. | | | | |
| 💼 2 An APRA-regulated entity would typically select cryptographic techniques based on the nature of the activity and the sensitivity and criticality of the data involved. The cryptographic techniques would typically be reviewed on a regular basis to ensure that they remain commensurate with vulnerabilities and threats. | | | | |
| 💼 3 APRA envisages that a regulated entity would select encryption algorithms from the population of well-established and proven international standards that have been subjected to rigorous public scrutiny and verification of effectiveness. The length of a cryptographic key would typically be selected to render a brute force attack9 impractical (i.e. would require an extremely long period of time to breach using current computing capabilities). | | | | |
| 💼 4 Cryptographic key management refers to the generation, distribution, storage, renewal, revocation, recovery, archiving and destruction of encryption keys. Effective cryptographic key management ensures that controls are in place to reduce the risk of compromise of the security of cryptographic keys. Any compromise of the security of cryptographic keys could, in turn, lead to a compromise of the security of the information assets protected by the cryptographic technique deployed. | | 6 | 7 | |
| 💼 5 An APRA-regulated entity would typically deploy, where relevant, controls to limit access to cryptographic keys, including: | 6 | | | |
| 💼 a. use of physically and logically protected devices and environments to store and generate cryptographic keys, generate PINs and perform encryption and decryption. In most cases this would involve the use of Hardware Security Modules10 (HSMs) or similarly secured devices; | | | | |
| 💼 b. use of cryptographic techniques to maintain cryptographic key confidentiality; | | | | |
| 💼 c. segregation of duties, with no single individual having knowledge of the entire cryptographic key (i.e. two-person controls) or having access to all the components making up these keys; | | | | |
| 💼 d. predefined activation and deactivation dates for cryptographic keys, limiting the period of time they remain valid for use. The period of time a cryptographic key remains valid would be commensurate with the risk; | | 3 | 4 | |
| 💼 e. clearly defined cryptographic key revocation processes; | | | | |
| 💼 f. the deployment of detection techniques to identify any instances of cryptographic key substitution. | | | | |
| 💼 Attachment F - Customer security | 1 | | | |
| 💼 1 Products and services delivered via digital channels can introduce additional information security vulnerabilities which, if exploited, could result in potentially material information security incidents impacting beneficiaries. APRA-regulated entities would typically implement preventative, detective and response controls commensurate with these risks. Common controls include: | 5 | | | |
| 💼 a. authentication controls commensurate with the vulnerability and threats associated with the products and services offered. This could include usage of a second channel notification/confirmation of events (e.g. account transfers, new payees, change of address, access from an unrecognised device); | | | | |
| 💼 b. limits to ensure losses are within risk tolerances (e.g. transfer limits, daily transaction limits); | | | | |
| 💼 c. transaction activity monitoring to detect unusual patterns of behaviour and review of loss event trends which may trigger the need for additional controls (e.g. fraud and theft losses); regular review of customer education and security advice to ensure that it remains adequate and aligned with common industry practice; | | | | |
| 💼 d. documented and communicated procedures for incident monitoring and management of fraud, data leakage and identity theft; | | | | |
| 💼 e. minimising the collection of sensitive customer information beyond what is relevant to the business activities undertaken. This includes customer information used for the purposes of authentication, such as passwords/PINS. | | | | |
| 💼 Attachment G - Testing techniques | 14 | | | |
| 💼 Authenticate users with strength of authentication commensurate with sensitivity of the information asset being accessed | | | | |
| 💼 Implement secure software | | | | |
| 💼 Implementation controls minimise risk of new vulnerabilities from system change, systems are secure by design | | | | |
| 💼 Inform decision-makers of the sufficiency of information security and direct activity as appropriate | | | | |
| 💼 Limit access to what has been authorised based on job role and principle of least privilege | | | | |
| 💼 Orderly response to information security incidents | | | | |
| 💼 Protect networks from unauthorised network traffic | | | | |
| 💼 Protect system-to-system communication, including exchange of data, from unauthorised access and use | | | | |
| 💼 Protect systems from malicious attacks | | | | |
| 💼 Recovery under all plausible scenarios | | | | |
| 💼 Resilience of systems to handle failure of individual components | | | | |
| 💼 Timely detection of unauthorised access and use | | | | |
| 💼 Timely identification and remediation of new threats | | | | |
| 💼 Timely identification and remediation of new vulnerabilities | | | | |
| 💼 Attachment H - Reporting | 2 | | | |
| 💼 Common information reported to Boards and management | 4 | | | |
| 💼 Capability | | | | |
| 💼 Controls | | | | |
| 💼 Education | | | | |
| 💼 Incidents | | | | |
| 💼 Common metrics reported to Boards and management | 6 | | | |
| 💼 Events - On compromise | | | | |
| 💼 Events - Post compromise | | | | |
| 💼 Events - Pre compromise | | | | |
| 💼 Practices - On compromise | | | | |
| 💼 Practices - Post compromise | | | | |
| 💼 Practices - Pre compromise | | | | |