prudential practice guide cpg 234 management of security risk may 2013

8/19/2019 Prudential Practice Guide CPG 234 Management of Security Risk May 2013

1/29

Prudential Practice GuideCPG 234 – Management of Security Risk inInformation and Information TechnologyMay 2013

www.apra.gov.au

Australian Prudential Regulation Authority


2/29

Australian Prudential Regulation Authority 2

Disclaimer and copyright

This prudential practice guide is not legal advice andusers are encouraged to obtain professional adviceabout the application of any legislation or prudentialstandard relevant to their particular circumstances andto exercise their own skill and care in relation to any

material contained in this guide.APRA disclaims any liability for any loss or damagearising out of any use of this prudential practice guide.

© Australian Prudential Regulation Authority (APRA)

This work is licensed under the Creative CommonsAttribution 3.0 Australia Licence (CCBY 3.0).

This licence allows you to copy,distribute and adapt this work, provided you attributethe work and do not suggest that APRA endorses youor your work. To view a full copy of the terms of this

licence, visit www.creativecommons.org/licenses/by/3.0/au/.

http://users/nicolewatts/Library/Caches/Adobe%20InDesign/Version%207.5/en_GB/InDesign%20ClipboardScrap1.pdfhttp://users/nicolewatts/Library/Caches/Adobe%20InDesign/Version%207.5/en_GB/InDesign%20ClipboardScrap1.pdfhttp://users/nicolewatts/Library/Caches/Adobe%20InDesign/Version%207.5/en_GB/InDesign%20ClipboardScrap1.pdfhttp://users/nicolewatts/Library/Caches/Adobe%20InDesign/Version%207.5/en_GB/InDesign%20ClipboardScrap1.pdfhttp://users/nicolewatts/Library/Caches/Adobe%20InDesign/Version%207.5/en_GB/InDesign%20ClipboardScrap1.pdf


3/29


Prudential practice guides (PPGs) provide guidanceon APRA’s view of sound practice in particular areas.PPGs frequently discuss statutory requirementsfrom legislation, regulations or APRA’s prudentialstandards, but do not themselves create enforceablerequirements.

This PPG aims to assist regulated institutions in themanagement of security risk in information andinformation technology (IT). It is designed to provideguidance to senior management, risk managementand IT security specialists (management and

operational).The PPG targets areas where APRA continues toidentify weaknesses as part of its ongoing supervisoryactivities. The PPG does not seek to provide an all-encompassing framework, or to replace or endorseexisting industry standards and guidelines.

Subject to meeting APRA’s prudential requirements,regulated institutions have the flexibility to managesecurity risk in IT in a manner best suited to achievingtheir business objectives. Not all of the practicesoutlined in this prudential practice guide will be

relevant for every regulated institution and someaspects may vary depending upon the size, complexityand risk profile of the institution.

For the purposes of this guide, in the context of thesuperannuation industry, a reference to a ‘customer’,includes a beneficiary of a registrable superannuationentity (RSE).

About this guide


4/29


Contents

Introduction 6

IT security risk 7

Definition 7

Risk management 8

Classification by criticality and sensitivity 8

Industry baselines 8

An overarching framework 9

Hierarchy of policies, standards, guidelines and procedures 9 A principles-based approach 9

Policy domains 10

Ongoing compliance 10

Ongoing assessment of effectiveness 11

User awareness 11

Training and awareness programs 11

User education areas 11

User compliance 12

Access Control 12

Access based on business need 12

Identification and authentication techniques 12

Access control techniques 12

Data/information leakage 13

Cryptographic techniques to restrict access 14

IT asset life-cycle management controls 14

IT security considered at all stages 14

Physical security 15

Secure software development 15

IT security technology solutions 15

End-user developed/configured software 15

Legacy technologies 16

Emerging technologies 16


5/29


Monitoring and incident management 16 Monitoring processes 16

Incident management 17

Accountability and audit trails 17

IT security reporting and metrics 17

Regular reporting 17

Effective IT security metrics 18

IT security assurance 18 Assurance program 18

Frequency of assurance 18

Independence 18

Attachment A: Change management 19

Attachment B: Resilience and recovery 20

Attachment C: Service provider management 23

Attachment D: Secure software development 24

Attachment E: Customer protection 26

Attachment F: Cryptographic techniques 27


6/29


Introduction1. Continued developments in information1 and

information technology (IT)2 have broughtabout an increased reliance by financial serviceorganisations on IT assets3 , including software,hardware and data/information (both soft andhard copy). Consequently, stakeholders includingBoards of Directors (Boards), senior management,shareholders, customers and regulators haveheightened expectations regarding the effectivesafeguarding of IT assets. For ease of reference,the term ‘IT’ in this document relates to bothinformation and information technology.

2. This prudential practice guide (PPG) targets areaswhere IT security risk management weaknessescontinue to be identified as part of APRA’songoing supervision activities. While the PPGprovides guidance for safeguarding IT assets,it does not seek to be an all-encompassingframework. APRA expects that regulatedinstitutions, using a risk-based approach, willimplement appropriate controls for IT assets evenin areas not addressed by this PPG.

3. This PPG aims to provide guidance to seniormanagement, risk management and IT securityspecialists (management and operational)in APRA-regulated institutions. The multipleaudiences reflect the pervasive nature of ITsecurity risk management, and the need forsound risk management disciplines and solidbusiness understanding to evaluate and managethe IT security risk profile. Additionally, effectiveIT security risk management can facilitatebusiness initiatives and assist compliance withother regulatory requirements (e.g. privacy andanti-money laundering).

4. As with any process, governance is vital to ensurethat risk management processes are properlydesigned and operating effectively to meet theneeds of the institution. In APRA’s view, effectivegovernance of IT security risk managementwould be aligned to the broader IT and corporategovernance frameworks and involve the cleararticulation of Board and senior managementresponsibilities and expectations, formally delegatedpowers of authority, and regular oversight.

5. Subject to APRA’s prudential standards, an

APRA-regulated institution has the flexibility tomanage IT security risks in the way most suitedto achieving its business objectives. Where thecontent of this PPG touches on matters containedin the prudential standards, the intent is toprovide guidance where the standards relate to ITsecurity risk management.

6. This PPG does not seek to replace or endorseexisting industry standards and guidelines. Aregulated institution would typically use discretionin adopting whichever industry standards it

sees fit for purpose in specific control areas. Inaddition, the level, scope and language usedwithin this PPG reflect a broader target audience,coming from a variety of disciplines and levelswithin an organisation. In APRA’s view, usefulguidance may also be obtained from industry-accepted standards such as COBIT4 , ISOstandards5, Standards Australia6 and ITIL7 in thatthey provide broad frameworks for establishingand maintaining control environments.

1 Information is the result of processing, manipulating and organising data.

2 Computer-based technology comprising software, hardware and data.

3 Anything deemed to be of value (either financial or otherwise) by an organisation, pertaining to IT.

4 Control Objectives for Information and related Technology (COBIT) issued by the Information Systems Audit and Control Association (US-based).

5 As issued by the International Organization for Standardization (ISO), an international standards-setting body headquartered in Switzerland.6 A non-government Australian-based standards development body.

7 IT Infrastructure Library (ITIL) issued by the Office of Government Commerce (UK-based).


7/29


8/29


Risk management14. In APRA’s view, IT security risk (as with the

broader set of IT risks) will ultimately result ina business risk exposure. Regulated institutionswould benefit from clearly defining both ITrisk and IT security risk. In addition, allocationmechanisms would typically be developed formapping these risks to business risks, based onrelevant risk categorisations, enabling allocationof individual and aggregate risks to thoseaccountable for ownership, management and

control of risk. This includes the ability to assessthese risks both within and across business units,including at the enterprise level.14

15. Regulated institutions have developed distinctpractices and disciplines to manage IT securityrisks, IT risks and operational risks. In APRA’sview, these are all necessary and complementarydisciplines.

16. An important goal of IT security risk management(as with the broader set of IT risks) is to ensurethat the business objectives of the institutioncontinue to be met. It is important that anindividual business unit’s objectives are notconsidered in isolation but rather in the contextof the objectives of the institution as a whole.

17. In APRA’s view, IT risk exposures that could havea material impact on a regulated institution wouldtypically be controlled/mitigated to a level thatensures the institution’s ability to meet regulatoryand prudential requirements or operate as a goingconcern is not compromised by an incident.15

18. The adequacy of IT security controls in ensuringthat a regulated institution remains within its riskappetite would normally be assessed on a regularbasis (or following material change to either theinternal control or external environments). Theassessment would typically take into accountthe end-to-end control environment (includingmitigating controls). Changes to the controlenvironment would follow normal business casepractices, taking into account the likelihood andimpact of an event against the cost of the control.

19. The IT security risk management process is acontinuous and dynamic process that ensuresemerging IT vulnerabilities/threats16 areidentified, assessed and appropriately managed17 in a timely manner.

Classification by criticality and sensitivity

20. For the purposes of managing IT risk, a regulatedinstitution would typically classify IT assets basedon business criticality and sensitivity. Institutionsmay seek to leverage the existing business

impact analysis process to achieve this. Theinstitution’s IT asset classification method andgranularity would normally be determined by therequirements of the business.

Industry baselines

21. A regulated institution could find it useful toregularly assess the completeness of its IT securityrisk management framework by comparison topeers and established control frameworks andstandards.

14 The ability to aggregate and assess risks at the enterprise (whole-of-business) level is an important component of the identification and managementof emerging and growing risks.

15 For the purposes of this PPG, incidents are any events that potentially compromise the confidentiality, integrity and availability of IT assets.16 Threats relate to the potential compromise of IT assets through the exploitation of vulnerabilities.

17 Alternative ways of managing include mitigation, termination, transfer or acceptance of the risk exposure.


9/29


An overarching framework

Hierarchy of policies, standards, guidelinesand procedures

22. An IT security risk management frameworkoutlines a regulated institution’s approach tomanaging IT security and is typically embodiedin a hierarchy of policies, standards, guidelinesand procedures. It would typically align toother enterprise frameworks such as project

management, outsourcing management and riskmanagement.

23. The IT security risk management frameworkwould typically enable the design andimplementation of the IT security controls.The strength of controls would normally becommensurate with the criticality and sensitivityof the IT asset involved.

24. The establishment and ongoing developmentof the IT security risk management frameworkwould normally be directed by an overarching

IT security strategy and a supporting program ofwork. This strategy would typically be aligned witha regulated institution’s IT and business strategies,as appropriate.

25. In APRA’s view, the IT security risk managementframework would encapsulate the expectationsof the Board and senior management, have adesignated owner(s), and outline the roles andresponsibilities of staff to ensure the achievementof effective IT security risk managementoutcomes. The framework would be formally

approved and reviewed on a regular basis, withperiodic assessment for completeness againstcurrent practices and industry standards.

A principles-based approach26. APRA envisages that a regulated institution would

adopt a set of high-level IT security principles inorder to establish a sound foundation for the ITsecurity risk management framework. CommonIT security principles include:

(a) defence-in-depth and diversity of controls,where multiple layers and types of controlsare used to address risks in different ways.Therefore, should one control layer becompromised, other control(s) limit theimpact on a regulated institution;

(b) denial of all features, permissions, functionsand protocols unless required to conductbusiness operations. This reduces thenumber of attack approaches that may beused to compromise IT assets;

(c) timely detection and reporting of IT securitybreaches. This minimises the time in which acompromise of an IT asset can impact on aregulated institution;

(d) appropriately controlled error handling.Errors should not allow unauthorisedaccess to IT assets or other IT securitycompromises;

(e) distrust of unfamiliar IT assets, includinginternal and external IT assets. Such assetshave an unknown and possibly reduced levelof IT security control;

(f) segregation of duties, enforced throughappropriate allocation of roles and

responsibilities. This reduces the potential forthe actions of one person to compromise ITassets; and

(g) a control environment designed to enforcecompliance rather than assume staffare fully familiar with IT security policiesand procedures.


10/29


Policy domains27. Sound practice would be to establish policies with

supporting standards, guidelines and proceduresin the following areas, with higher level policiesnormally linked to desired business outcomes.A policy framework would normally take intoconsideration:

(a) identification, authorisation and granting ofaccess to IT assets (by individuals and otherIT assets);

(b) definition of an overarching IT securityarchitecture that outlines the directionfor the design of the IT environment(encompassing all IT assets) from a securityperspective (e.g. network zones/segments,gateway design, authentication, identitymanagement, message routing, softwareengineering and location of IT securitytechnology solutions);

(c) life-cycle management that addresses thevarious stages of an IT asset’s life to ensure

that IT security requirements are consideredat each stage. This includes configurationstandards;

(d) management of IT security technologysolutions that include firewall, anti-malicioussoftware, intrusion detection/prevention,cryptographic systems and monitoring/loganalysis tools;

(e) monitoring and incident management toaddress the identification and classificationof incidents, reporting and escalation

guidelines, preservation of evidence and theinvestigation process;

(f) management and monitoring of serviceproviders that defines the framework foroverseeing the management of IT securityrisks by third parties;

(g) acceptable usage of IT assets that definesthe IT security responsibilities of users (staff,service providers and customers) in the useof IT assets;

(h) recruitment and selection of IT staff andcontractors that defines the framework forvetting and monitoring of personnel, takinginto account IT security risk; and

(i) IT security roles and responsibilities that mayinclude:

(i) IT security risk management frameworkroles: maintenance, ongoing review,compliance monitoring, training andawareness;

(ii) IT security-specific roles18: IT securitymanager/officer, administrators,specialists;

(iii) IT asset-specific roles: owners19,custodians, end-users;

(iv) risk management, assurance and

compliance roles; and(v) formally constituted IT governance

functions and reporting mechanisms toassess the ongoing effectiveness of theIT security risk management framework.

Ongoing compliance

28. A regulated institution would normally implementprocesses that ensure compliance with regulatoryand prudential requirements and the internalIT security risk management framework. APRA

envisages that this would include ongoing checksby the compliance function (or equivalent),supported by reporting mechanisms (e.g. metrics,exceptions) and management reviews.

18 Roles and responsibilities should not compromise appropriate segregation of duties (e.g. separation of security operations from policy setting andmonitoring functions).

19 In APRA’s view, IT asset owners are important in determining the level of acceptable residual risk.


11/29


29. A regulated institution would normally implementan exemption policy for handling instancesof non-compliance with the IT security riskmanagement framework including: managementof the exemption register; authority for grantingexemptions; expiry of exemptions; and the reviewof exemptions granted. Where exemptions aregranted, APRA envisages that an institution wouldreview and assess the adequacy of compensatingcontrols initially and on an ongoing basis.Compensating controls would normally reducethe residual risk in line with the institution’s riskappetite.

Ongoing assessment of effectiveness

30. APRA envisages that a regulated institutionwould regularly assess IT security vulnerabilitiesand evaluate the effectiveness of the existing ITsecurity risk management framework, makingany necessary adjustments to ensure emergingvulnerabilities are treated in a timely manner. Thisassessment would normally also be conducted as

part of any material change.31. A regulated institution would normally manage

the initial development and continuing updatesto the IT security risk management frameworkas an ongoing program of work. Subject to themateriality of changes to the IT security riskmanagement framework, the body of work wouldtypically be managed as a formal project with aclearly defined budget, resource requirements,timeframes and milestones, or using business-as-usual processes.

32. APRA envisages that control gaps identified in theIT security risk management framework would beaddressed in a systematic way. This may involvethe formulation of an IT security program thatspecifies target IT security metrics, timeframesfor resolution and associated action plans forclosing the gaps. Typically, action plans would beprioritised and tracked.

User awareness

Training and awareness programs

33. A regulated institution could benefit fromdeveloping an initial, and ongoing, trainingand IT security awareness program. Thiswould typically incorporate any changes in ITsecurity vulnerabilities or the institution’s ITsecurity risk management framework. Soundpractice would involve the tracking of training

undertaken and the testing of staff understandingas to the relevant IT security policies (both oncommencement and periodically).

User education areas

34. A regulated institution would regularly educateusers as to their responsibilities regarding securingIT assets. Common areas covered would normallyinclude:

(a) personal versus corporate use of IT assets;

(b) email usage, internet usage (including socialnetworking) and malware protection;

(c) physical protection, remote computing andusage of mobile devices;

(d) access controls including standards relatingto passwords and other authenticationrequirements;

(e) responsibilities with respect to any end-user developed/configured software(including spreadsheets, databases and office

automation);(f) handling of sensitive data/information; and

(g) reporting of IT security incidents andconcerns.

35. In the case of remote computing, a regulatedinstitution would normally make users aware ofthe increased IT security threats, particularly withrespect to unprotected environments.


12/29


User compliance36. A regulated institution would typically require

users to adhere to appropriate IT security policiespertinent to their roles and responsibilities. As aminimum, all users would typically be requiredto periodically sign-off on these policies as partof the terms and conditions of employment orcontractual agreements.

Access Control

Access based on business need

37. A key requirement for ensuring IT security isan effective process for providing access to ITassets. A regulated institution would normallyonly authorise access to IT assets where a validbusiness need exists and only for as long as accessis required.

38. Factors to consider when authorising access tousers and IT assets include: business role; physicallocation; remote access; time; patch and anti-

malware status; software; operating system;device; and method of connectivity.

39. The provision of access involves the followingprocess stages:

(a) identification and authentication:determination of who or what is requestingaccess and confirmation of the purportedidentity;

(b) authorisation: assessment of whether accessis allowed to an IT asset by the requestor

based on the needs of the business and thelevel of IT security (trust) required.

Identification, authentication and accessauthorisation processes are applicable to bothusers and IT assets.

Identification and authenticationtechniques

40. A regulated institution would normally takeappropriate measures to identify and authenticateusers or IT assets. The required strength ofauthentication would normally be commensuratewith risk.

41. Common techniques for increasing the strengthof identification and authentication includethe use of strong password techniques (i.e.

increased length, complexity, re-use limitationsand frequency of change) and increasing thenumber and/or type of authentication factorsused. Authentication factors include something aperson knows20, has21 and is22.

42. The following are examples where increasedauthentication strength is typically required, giventhe risks involved:

(a) administration or other privileged access tosensitive or critical IT assets;

(b) remote access (i.e. via public networks) tosensitive or critical IT assets; and

(c) high-risk activities (e.g. third-party fundtransfers, creation of new payees).

43. The period for which authentication is validwould be commensurate with the risk. Commontechniques for achieving this include sessiontimeouts and the use of time-limited one-timepasswords.

Access control techniques

44. A regulated institution would typically deploythe following controls to limit access to IT assets,based on a risk assessment:

(a) granting access based on a risk assessment.The use of contractors and temporarystaffing arrangements may elevate the risk

20 e.g. user IDs and passwords.21 e.g. a security token or other devices in the person’s possession used for the generation of one-time passwords.

22 e.g. retinal scans, hand scans, signature scans, digital signature, voice scans or other biometrics.


13/29


for certain roles;(b) implementation of role-based access profiles

which are designed to ensure effectivesegregation of duties;

(c) prohibiting the sharing of accounts andpasswords (including generic accounts);

(d) changing of default passwords and usernames;

(e) removal of access rights whenever there isa change in role or responsibility, and on

cessation of employment. Access rights canthen be granted in line with the new role orresponsibility, without risk of unnecessaryaccess remaining;

(f) processes to notify appropriate personnel ofuser additions, deletions and role changes;

(g) audit logging and monitoring of access to ITassets by all users;

(h) regular reviews of user access by IT assetowners to ensure appropriate access is

maintained;

(i) multi-factor authentication for privilegedaccess, remote access and other high-riskactivities;

(j) generation, in preference to storage, ofpasswords/PINs23 where these are used toauthorise high-risk activities (e.g. debit/creditcard and internet banking transactions); and

(k) two-person rule applied to extremelysensitive IT assets (e.g. encryption keys24, PIN

generation, debit/credit card databases).45. For accountability purposes, a regulated

institution would normally ensure that users andIT assets are uniquely identified and their actionsare auditable.

Data/information leakage46. ‘Data leakage’25 is defined as the unauthorised

removal, copying, distribution, capturing or othertypes of disclosure of sensitive data/information.Access to data removal methods would normallybe subject to risk assessment and only grantedwhere a valid business need exists.

47. Controls, commensurate with the sensitivity andcriticality of the data/information involved, wouldnormally be implemented where sensitive data/information is at risk of leakage. Examples of suchdata leakage methods include the use of: portablecomputing devices (e.g. laptops, PDAs, mobilephones); portable storage devices (e.g. USBflash drives, portable hard drives, writable disks);electronic transfer mechanisms (e.g. email, instantmessaging); and hard copy.

48. Common controls for data/information removalmethods would normally be commensuratewith risk. Users with a greater level of access tosensitive data/information would be subject toan increased level of scrutiny. Such controls couldinclude:

(a) authorisation, registration and regular reviewof users and associated transfer mechanismsand devices (including printers);

(b) appropriate encryption, cleansing andauditing of devices;

(c) appropriate segmentation of data/information based on sensitivity and accessneeds;

(d) appropriate blocking, filtering andmonitoring of electronic transfermechanisms and printing; and

(e) monitoring for unauthorised software andhardware (e.g. key loggers, password crackingsoftware, wireless access points, businessimplemented technology solutions).

23 Personal Identification Numbers (PINs) are a secret (usually numeric) password shared between a user and a system that can be used to authenticate

the user to the system.24 Refer to Attachment F for further guidance.

25 Sometimes referred to as data loss.


14/29


49. In APRA’s view, wholesale access to sensitivedata/information26 would be highly restrictedto reduce the risk exposure to significant dataleakage events. Industry experience of actualinstances in this area includes the leakage ofdebit/credit card details and the sale/trade orexploitation of customer identity information.

Cryptographic techniques to restrict access

50. In APRA’s view, cryptographic techniques wouldnormally be used to control access27 to sensitive

data/information, both in storage and in transit.The strength of the cryptographic techniquesdeployed would be commensurate with thesensitivity and criticality of the data/informationas well as other supplementary or compensatingcontrols. (Refer to Attachment F for furtherguidance.)

51. In order to minimise the risk of compromise, anend-to-end approach would normally be adopted,where encryption is applied from the point ofentry to final destination.

IT asset life-cycle managementcontrols

IT security considered at all stages

52. APRA envisages that a regulated institutionwould ensure that IT security is considered atall stages of an IT asset’s life-cycle28. This couldinvolve the use of external advisers whereexpertise is not available internally. Life-cycle

stages typically include: planning and design;acquisition and implementation; support andmaintenance; and decommissioning and disposal.Regulated institutions would usually apply projectmanagement techniques to manage materialchanges during these stages and to ensure thatIT security requirements have been adequatelyaddressed.

53. Planning and design controls would typically bein place to ensure that IT security is embodied inthe overall IT architecture. Solutions implementedwould normally comply with the IT securityrequirements of a regulated institution (asembodied in the IT security risk managementframework), including availability considerations(refer to Attachment B for further guidance).

54. Acquisition and implementation controlswould typically be in place to ensure that theIT security of the technology environment is

not compromised by the introduction of newIT assets. Ongoing support and maintenancecontrols would typically be in place to ensure thatIT assets continue to meet business objectives.Examples of controls include:

(a) change management controls to ensure thatthe business objectives continue to be metfollowing change (refer to Attachment A forfurther guidance);

(b) configuration management controls toensure that the configuration minimises

vulnerabilities and is defined, assessed,registered and maintained;

(c) deployment and environment controlsto ensure that development, test andproduction environments are appropriatelysegregated and enforce segregation of duties;

(d) patch management controls to manage theassessment and application of patches tosoftware that address known vulnerabilitiesin a timely manner;

(e) service level management: mechanisms tomonitor, manage and align IT security withbusiness objectives;

(f) capacity and performance managementcontrols to ensure that the current andprojected requirements of the business aremet; and

26 e.g. contents of customer data bases or intellectual property that can be exploited for personal gain.27 Cryptographic techniques may also be used to verify data/information integrity.

28 Refers to the life-cycle of IT assets more broadly, not just to the software development life-cycle.


15/29


(g) service provider (including vendor)management controls to ensure thata regulated institution’s IT securityrequirements are met by service providers.

55. Decommissioning and destruction controlsare used to ensure that IT security is notcompromised as IT assets reach the end of theiruseful life. Examples include archiving strategiesand the deletion of sensitive information prior tothe disposal of IT assets.

Physical security56. The strength of the environmental controls

would normally be commensurate with thesensitivity and criticality of the IT asset(s). Theabsence of physical security could compromisethe effectiveness of other IT security controls. Aregulated institution would normally deploy thefollowing environmental controls:

(a) location and housing that provide a levelof protection from natural and man-madethreats;

(b) restricted access to sensitive areas. Thisincludes procedures for handling access bystaff, third party providers and visitors; and

(c) monitoring and alert mechanisms for thedetection of compromises of environmentalcontrols including: temperature; water;smoke and access sensors/alarms;service availability alerts (power supply,telecommunication, servers); and access logreviews.

Secure software development

57. A regulated institution would normally considerIT security at all stages of software development.This would assist in maintaining confidentiality,integrity and availability by improving softwarequality and minimising exposure to vulnerabilities(refer to Attachment D for further guidance).

IT security technology solutions58. A regulated institution typically deploys specific

technology solutions in key locations to controlor monitor the security of various IT assets.Examples include: firewalls; network accesscontrol; intrusion detection/prevention devices;anti-malware; encryption and monitoring/log analysis tools. The degree of reliance that isplaced on these technology solutions and theircriticality and sensitivity necessitate a heightenedset of life-cycle controls, including but not limited

to:(a) guidelines outlining when IT security-specific

technology solutions should be used;

(b) standards documenting the detailedobjectives and requirements of individual ITsecurity-specific technology solutions;

(c) authorisation of individuals who can makechanges to IT security-specific technologysolutions. This would normally take intoaccount segregation of duties issues; and

(d) regular assessment of the IT security-specifictechnology solutions configuration, assessingboth continued effectiveness as well asidentification of any unauthorised changes.

End-user developed/configured software

59. Current technologies allow for end-users todevelop software for the purpose of automatingday-to-day business process or facilitatingdecision-making. In addition, software isincreasingly designed to be configurable by end-users. This creates the risk that inadequate life-cycle controls are in place for critical IT assets.

60. A regulated institution would normally introduceprocesses to identify the existence of end-userdeveloped/configured software and assess its riskexposure. In APRA’s view, any IT software assetthat is critical to achieving the objectives of thebusiness, or processes sensitive data/information,would comply with the relevant life-cyclemanagement controls of the institution.


16/29


Legacy technologies61. IT assets that have been implemented prior to

an institution’s current IT security managementframework may not comply with the framework’srequirements. In such instances, the institutionwould typically, as part of its risk managementprocesses, formulate a strategy for eitherthe replacement of the IT assets and/or theimplementation of appropriate compensatingcontrols commensurate with the institution’srisk appetite. Variations from the IT security

management framework would normally becaptured in an exemption register.

Emerging technologies

62. New technologies potentially introduce a setof additional risk exposures (both known andunknown). A regulated institution would normallyapply appropriate caution when considering theintroduction of new technologies.

63. Typically, a regulated institution would only

authorise the use in a production environment oftechnologies:

(a) that have matured to a state where there isa generally agreed set of industry-acceptedcontrols to manage the security of thetechnology; or

(b) where compensating controls are sufficientto comply with the institution’s risk appetite(e.g. network segmentation).

64. A regulated institution may find it useful todevelop a technology authorisation process andmaintain an approved technology register tofacilitate this. The authorisation process wouldtypically involve a risk assessment balancing thebenefits of the new technology with the risk(including an allowance for uncertainty).

Monitoring and incidentmanagement

Monitoring processes

65. A regulated institution would normally havemonitoring processes in place to identify eventsand unusual patterns of behaviour that couldimpact on the security of IT assets. The strengthof the monitoring controls would typically becommensurate with the criticality and sensitivity

of an IT asset. APRA envisages that alerts wouldbe investigated in a timely manner, with anappropriate response determined.

66. Common monitoring processes include:

(a) activity logging including exceptions toapproved activity (e.g. device, server andnetwork activity; security sensor alerts);

(b) environment and customer profiling;

(c) checks to determine if IT security controlsare operating as expected and are being

complied with; and

(d) monitoring staff or third-party access tosensitive data/information to ensure it is fora valid business reason.

67. APRA envisages that a regulated institution wouldestablish a clear allocation of responsibility forregular monitoring, with appropriate processesand tools in place to manage the volume ofmonitoring required, thereby reducing the risk ofan incident going undetected.

68. Highly sensitive and/or critical IT assets wouldtypically have logging enabled to record eventsand monitored at a level commensurate with thelevel of risk.

69. Users with elevated access entitlements (e.g.system administrators) would normally be subjectto a greater level of monitoring in light of theheightened risks involved.


17/29


70. Access controls and segregation of duties wouldnormally be used as a means to safeguard theintegrity of the monitoring logs and processes.

Incident management

71. APRA envisages that a regulated institutionwould develop appropriate processes to manageall stages of an incident that could impact onservices including detection, identification,containment, investigation, evidence gathering,resolution, return to business-as-usual and

reducing the risk of similar future events.Common incident types include:

(a) outages/degradation of services due tohardware, software or capacity issues;

(b) unauthorised access to IT assets;

(c) data leakage;

(d) identity theft;

(e) malicious software and hardware;

(f) fraud;

(g) failed backup processes;

(h) denial of service attacks; and

(i) data integrity issues.

72. A regulated institution would normally have clearaccountability and communication strategiesto limit the impact of IT security incidents. Thiswould typically include defined mechanisms forescalation and reporting to the Board and seniormanagement and customer communication

where appropriate (refer to Attachment Efor further guidance). Incident managementstrategies would also typically assist in compliancewith regulatory requirements. Institutions wouldnormally notify APRA after experiencing a majorincident.

73. Incidents would typically be subject to root causeanalysis, where the underlying cause(s) of theincident is identified and analysed and controlsadjusted to reduce the likelihood and impact of afuture occurrence.

Accountability and audit trails74. APRA envisages that a regulated institution would

ensure audit trails exist for IT assets that: satisfythe institution’s business requirements (includingregulatory and legal); facilitate independentaudit; assist in dispute resolution (includingnon-repudiation); and assist in the provision offorensic evidence if required. This could include,as applicable:

(a) the opening, modification or closing ofcustomer accounts;

(b) any transaction with financial consequences;

(c) authorisations granted to customers toexceed a pre-approved limit;

(d) accessing or copying of sensitive data/information; and

(e) granting, modification or revocation ofsystems access rights or privileges foraccessing sensitive IT assets.

75. Audit trails would typically be secured to ensure

the integrity of the information captured,including the preservation of evidence. Retentionof audit trails would normally be in line withbusiness requirements (including regulatory andlegal).

IT security reporting and metrics

Regular reporting

76. A regulated institution would typically develop a

formalised IT security reporting framework thatprovides operational information and oversightacross the various dimensions of the IT securityrisk management framework. The frameworkwould incorporate clearly defined reporting andescalation thresholds and reflect the variousaudiences responsible for either acting on orreviewing the reports. Reporting mechanismswould typically ensure appropriate considerationof both risk and control dimensions.


18/29


77. In APRA’s view, there would normally besufficient management reporting to enableeffective oversight of the performance of theIT security management function in meeting itsstated objectives. Reporting may include: riskprofile(s); exposure analysis; progress againststrategy; incident analysis; system capacityand performance analysis; recovery status;infrastructure and software analysis; projectassessment and analysis; audit findings and ageingreports; and fraud analysis.

Effective IT security metrics

78. IT security metrics can be useful mechanismsfor assessing the success of the IT securityrisk management framework in maintainingconfidentiality, integrity and availability, andare usually included in IT security reporting. InAPRA’s view, each dimension of the IT securityrisk management framework would be measuredby at least one metric to enable the monitoring ofprogress towards set targets and the identification

of trends.79. APRA envisages that the use of metrics would be

targeted towards the areas of greatest criticalityand sensitivity as determined through therisk assessment process. Effective metrics arespecific, measurable, business-impact oriented,controllable and reportable. In addition, acomprehensive set of metrics would include bothbackward – and forward-looking measures (i.e.key performance indicators (KPIs) and key riskindicators (KRIs)).

IT security assurance

Assurance program

80. APRA expects that a regulated institutionwould seek regular assurance that IT assets areappropriately secured and that its IT security riskmanagement framework is effective. This wouldnormally be executed through a formal programof work that facilitates a systematic assessment ofthe IT security risk and control environment over

time.

Frequency of assurance

81. A regulated institution would benefit from amulti-year schedule of testing that incorporatesboth adequacy and compliance-type reviews,with the program of work determined on a riskbasis. Additional assurance work may be triggeredby changes to vulnerabilities/threats or materialchanges to IT assets.

82. The schedule of testing would typically

ensure that all aspects of the IT securitycontrol environment are assessed over time,commensurate with the sensitivity and criticalityof the IT assets. In APRA’s view, annual testing(as a minimum) would be normal for IT assetsexposed to ‘un-trusted’ environments.29

Independence

83. Traditionally, assurance work has been executedby Internal Audit. However, given the specialistnature of this work, other appropriately trainedand sufficiently independent (to avoid conflictsof interest) IT security experts could be used tocomplement such work. APRA envisages that anyfindings would be reported and monitored usingthe established audit/compliance issue trackingprocess.

29 Environments where a regulated institution is unable to enforce IT security policy (e.g. public networks).


19/29


1. APRA envisages that a regulated institution wouldimplement controls to manage change to ITassets with the aim of maintaining confidentiality,integrity and availability. This includes changesto hardware, software (including associatedconfigurations) and data fixes.

2. Key components of effective change controlinclude: registration of proposed changes; impactassessment; change scheduling; and approval ofchanges prior to deployment into the productionenvironment. Change management aims to

balance the need for change with the potentialdetrimental impact of the change. Commoncomponents of change control that a regulatedinstitution would normally deploy include:

(a) changes to the production environment(including planned and emergency changesto software, hardware and data) developedand verified in another environment30,sufficiently segregated from production so asto avoid any compromise of IT security;

(b) testing environments that are representative

of production in order to reduce the riskof changes in behaviour when deployed toproduction;

(c) IT security review points at all stages of thechange life-cycle to ensure that securitycontrols are identified, designed, constructedand tested so that the level of securitycontinues to meet business objectives.The level of review would typically becommensurate with the risk associated withthe change and could range from peer review

to independent vulnerability assessment;

(d) various levels of formal testing (such as unit,module, regression, system, integration,sociability, performance, security and useracceptance testing) followed by formalsign-off (from the business and otherimpacted areas) prior to deployment into theproduction environment;

(e) desensitising production data/informationwhen it is used for testing purposes;

(f) segregation of duties in place between staffactioning a change and those deploying achange to production;

(g) changes scheduled and reviewed to ensurethat multiple changes made at the same timedo not conflict with each other;

(h) processes that provide reasonable assurancethat system recovery procedures and

components are in place at the time ofdeployment to production so that recoveryrequirements can be met; and

(i) implementation plans that include, asappropriate, a back-out/fall-back strategythat provides reasonable assurance thata failed deployment can be reversed orotherwise managed.

30 A regulated institution would typically run multiple environments reflecting the various stages of software development and testing (e.g. development,system testing, user acceptance testing, staging, etc.).

Attachment A: Change management


20/29


21/29


(f) a communication plan for notifying keyinternal and external stakeholders if aregulated institution’s recovery plan isinvoked; and

(g) an IT business continuity plan. Thisdocumentation would typically be focusedon operational processes and procedures theIT unit would follow while operating from analternate site.

8. Where the enactment of a recovery plan is reliantupon a third party, appropriate arrangements

would normally be established to secure serviceswithin the timeframes required. It would bebeneficial to verify this periodically to ensurerecovery timeframes are achievable.

9. A regulated institution would normally testsystem resilience and recovery capabilities at leastannually to verify that business continuity andrecovery requirements are achievable and thatrecovery plans remain current. The institutionwould benefit from a multi-year schedule oftesting that incorporates verification of recovery

at both the whole-of-site and component levels.

10. It is important that the success criteria for thetesting of resilience and recovery are clearlydefined, including the circumstances under whichre-testing would be required. Test results andassociated follow-up actions are typically formallytracked and reported.

11. It is also important that controls are in placeto ensure that IT security is not compromisedthroughout the testing process. This would

include access to and the secure destruction ofsensitive data/information after the test.

12. APRA envisages that a regulated institution wouldregularly backup critical and sensitive IT assets,regardless of the level of resilience in place.Appropriate controls would be implemented toensure the security of the backups is maintainedwhile in transit and storage, typically via physicalsecurity and cryptographic techniques. Recoveryprocedures would normally be regularly tested toensure that they are adequate to achieve effectiverecovery from backups.

13. All components required to enact the recovery

plans would typically be located at a sufficientdistance from the operational site(s) so thatthey are not impacted by the same disaster. Thisincludes: recovery sites and hardware; backups ofdata/information and software; and copies of therecovery plans.

14. In the case where a regulated institutionhas contractual arrangements for recoveryfacilities that are shared with a number of otherorganisations, the contract between a regulatedinstitution and the alternate site provider would

normally guarantee access to the minimumIT assets required to operate under a disasterscenario.

15. Refer to APRA’s Prudential Standards, PracticeGuides and guidance notes with respectto Business Continuity Management andOutsourcing for APRA’s requirements andguidance in this area.33

Offshore IT assets

16. For regulated institutions that have critical systemcomponents (processing and/or data) locatedoffshore, sound practice would involve thedevelopment of recovery strategies, plans andassociated arrangements, to address the scenariowhere the component located offshore becomesunavailable for an undefined period of time. Thiswould address scenarios based on man-made andnatural disaster events, and the financial failure ofthe institution maintaining the systems.

33 CPS 232; SPS 232; LPG 232; CPG 233; Prudential Standard CPS 231 Outsourcing (CPS 231); Prudential Standard SPS 231 Outsourcing (SPS 231); PrudentialPractice Guide PPG 231 Outsourcing (PPG 231) and Prudential Practice Guide SPG 231 Outsourcing (SPG 231).


22/29


17. In APRA’s view, recovery strategies, plans andassociated arrangements would be designedto ensure that a regulated institution maintainscontrol over the IT assets pertaining to theAustralian-regulated operations. This would befacilitated by:

(a) documentation that clearly identifies therelevant IT assets (e.g. an asset inventory andsystems architecture diagrams);

(b) sufficient segregation of IT assets pertainingto the Australian-regulated operations from

other systems to allow their separation ifrequired; and

(c) contractual protection to ensure access to ITassets pertaining to the Australian-regulatedoperations. This includes defining ownershipand jurisdiction of the IT assets.

18. APRA envisages that recovery of IT assetspertaining to the Australian-regulated operationswould be to a location that is not likely to besubject to the same disaster (including man-

made).19. In the case of a foreign subsidiary, under the

scenario of the financial failure of the Group,recovery plans would normally be in place toenable repatriation of sufficient data/informationto enable an orderly transition of operations (e.g.customer balances and transaction history).


23/29


1. IT security risks need to be appropriatelymanaged regardless of whether activities andassociated IT assets are under the direct controlof a regulated institution or have been outsourcedto a service provider. Where a service provider(including a software vendor) has been engaged,the due diligence, the formulation of the serviceagreement and the ongoing monitoring of theservice provider would all normally be structuredso as to facilitate oversight of the management ofall such risks, commensurate with the sensitivityand criticality of the IT assets impacted.

2. Appropriate due diligence would normally ensurean assessment as to the robustness of the ITsecurity risk management framework of theservice provider, and alignment with a regulatedinstitution’s own framework.

3. Effective service agreements normally embodya regulated institution’s IT security principlesand associated requirements. A regulatedinstitution would normally reflect relevant areasof its IT security framework in the agreement,

thereby ensuring that its IT security stance is notcompromised or weakened by the use of a serviceprovider.

4. The service agreement would include reportingmechanisms that ensure adequate oversight of ITsecurity risk management by the service provider.Oversight would typically involve the assessmentof the following items against a regulatedinstitution’s IT security requirements:

(a) service level reporting against agreed ITsecurity metrics (e.g. availability, incident

response timeframes);

(b) results of business continuity and recoverytesting and associated follow-up actions;

(c) post-incident reporting including rectificationactions, timeframes and root cause analysis;

(d) relevant compliance, audit and IT securitytesting reports and associated follow-upactions;

(e) handling of sensitive data/information; and(f) notification of material changes by

the service provider to the technologyenvironment; relevant policies, standards,and procedures; or changes to personnel,including the use of subcontractors.

5. Refer to APRA’s Prudential Standardsand guidance on Outsourcing for APRA’srequirements and guidance in this area.34

34 CPS 231; SPS 231; PPG 231 and SPG 231.

Attachment C: Service provider management


24/29


25/29


26/29


1. APRA envisages that a regulated institution wouldrevise and regularly review customer IT securityadvice to ensure that it remains adequate andappropriate relative to the institution’s risk profile.To help reduce the risk of being targeted for theperpetration of fraud, a regulated institution mayfind it beneficial to compare customer advicewith its peers, and the industry more broadly, on aregular basis.

2. A regulated institution would normally advise onmeasures for customers to protect themselves

against fraud and identity theft. Examples ofadvice given would typically include:

(a) not disclosing personal, financial or debit/credit card information unnecessarily orwhere the integrity of the recipient issuspect;

(b) when conducting banking activities, takingsafeguards to ensure no one else is able toobserve or access credentials or other ITsecurity information;

(c) using strong password controls by adoptingpasswords/PINS that are difficult to guess;changing passwords/PINS regularly; avoidingreuse of passwords/PINS; and not selectingthe option on browsers for storing orretaining user identifier and password/PIN;

(d) remaining alert for features to verify that awebsite or other media is bona fide and notaccepting links or redirections from otherwebsites or media for the purpose of loggingonto the institution’s website;

(e) remaining alert for suspiciouswebsites, emails, phone calls and othercorrespondence purporting to be from theinstitution, and reporting these immediatelyto the institution;

(f) advice as to monitoring account transactionsand balances on a regular basis;

(g) advice as to the process to follow should acustomer suspect they have been the victimof fraud/identity theft (including attempts

thereof);

(h) reminding customers that the institution willnot make unsolicited requests for sensitivecustomer information used for the purposesof authentication, such as passwords/PINS;and

(i) applying appropriate controls for securingcomputers and other devices used to accessbanking services.

3. A regulated institution’s controls for reducing therisk exposure of fraudulent activity, data leakage,or identity theft (in addition to those outlined

elsewhere in this PPG) would typically include:

(a) procedures for only collecting personalinformation relevant to the business activitiesundertaken and in compliance with relevantprivacy legislation;

(b) procedures for ensuring that under nocircumstances would a customer be asked toreveal sensitive customer information usedfor the purposes of authentication, such aspasswords/PINS;

(c) publication of customer privacy and relevantIT security policies such as customerdispute handling, reporting and resolutionprocedures and the expected timing of theinstitution’s response;

(d) usage of a second channel notification/confirmation of events (e.g. accounttransfers, new payees, change of address);

(e) implementation of appropriate limits onfinancial transactions; and

(f) documented and communicated proceduresfor incident monitoring and management offraud, data leakage and identity theft.

4. When communicating with customers in relationto IT security precautions and policies, it wouldbe more effective if regulated institutionsused plain language. In addition, it is normallypreferable to use consistent information across allcommunication channels (e.g. websites, accountstatements, promotional material and directcustomer contact).

Attachment E: Customer protection


27/29


1. Cryptographic techniques refer to methodsused to encrypt35 data/information, confirm itsauthenticity or verify its integrity. The followingare examples where regulated institutions coulddeploy cryptographic techniques given the risksinvolved :

(a) transmission and storage of critical and/orsensitive data/information in an ‘un-trusted’environment or where a higher degree ofsecurity is required;

(b) detection of any unauthorised alteration of

data/information;

(c) verification of the authenticity oftransactions or data/information; and

(d) the generation of customer PINs which aretypically used for debit/credit cards andonline services.

2. There are a variety of cryptographic techniquesthat a regulated institution can apply, eacheffective for a specific purpose. Cryptographictechniques can also be deployed that have varying

degrees of strength (i.e. levels of sophisticationof ciphers (algorithm) or hash36 functions and thelength of cryptographic keys37 applied).

3. A regulated institution would normally selectappropriate cryptographic techniques basedon the control effectiveness required and thesensitivity and criticality of the data/informationinvolved. The institution’s chosen cryptographictechniques would normally be reviewed ona regular basis to ensure that they remaincommensurate with the risk environment.

4. APRA envisages that a regulated institutionwould select algorithms from the populationof well established and proven internationalstandards that have been subjected to rigorouspublic scrutiny and verification of effectiveness(e.g. Triple DES38, AES39 etc.). The length of acryptographic key would typically be selectedto render a brute force attack40 impractical (i.e.would require an extremely long period of time tobreach using current computing capabilities).

5. Cryptographic key management refers to the

generation, distribution, storage, renewal,revocation, recovery, archiving and destructionof encryption keys. Effective cryptographic keymanagement ensures that controls are in place toreduce the risk of compromise of their security.Any compromise to the security of cryptographickeys may lead to a compromise of the securityof the IT assets protected by the cryptographytechnique deployed.

6. A regulated institution would typically deploy,where relevant, the following controls to limit

access to cryptographic keys, based on a riskassessment:

(a) additional physical protection of equipmentused to generate, store and archivecryptographic keys;

(b) use of cryptographic techniques to maintaincryptographic key confidentiality;

(c) segregation of duties, with no singleindividual having knowledge of the entirecryptographic key (i.e. two-person controls)

or having access to all the componentsmaking up these keys;

Attachment F: Cryptographic techniques

35 Encryption is the process of transforming information (referred to as plaintext) using an algorithm (called a cipher) to make it unreadable to anyoneexcept those possessing special knowledge, usually referred to as a key. Decryption is the reverse process.

36 A hash function takes data and returns a fixed-size bit string called the hash value. Any change to the data will change the hash value.

37 A piece of auxiliary information which changes the detailed operation of the cipher.

38 Triple DES is the common name for the Triple Data Encryption Algorithm (TDEA) block cipher.39 Advanced Encryption Standard (AES) block cipher.

40 A brute force attack is a method of defeating a cryptographic scheme by systematically trying a large number of possibilities.


28/29


(d) predefined activation and deactivation datesfor cryptographic keys, limiting the periodof time they remain valid for use. The periodof time a cryptographic key remains validcommensurate with the risk;

(e) clearly defined cryptographic key revocationprocesses; and

(f) the deployment of detection techniquesto identify any instances of cryptographickey substitution.

7. A regulated institution would typically utilisetamper resistant devices to store and generatecryptographic keys, generate PINs and performencryption and decryption. In most cases thiswould involve the use of Hardware SecurityModules41 (HSMs) or similarly secured devices.These devices would be appropriately securedboth physically and logically.

41 Hardware Security Module is a type of secure crypto-processor that provides for the secure generation and storage of cryptographic and othersensitive data/information.


29/29

Telephone

1300 55 88 49

Email

[email protected]

Website

www apra gov au 2 0 1 3_

e x
http://localhost/var/www/apps/conversion/tmp/scratch_4/[email protected]://www.apra.gov.au/http://www.apra.gov.au/http://localhost/var/www/apps/conversion/tmp/scratch_4/[email protected]

prudential practice guide cpg 234 management of security risk may 2013

Documents