| 💼 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. | | | | |