Our Principles
- We implement multiple layers and types of controls such that if one control fails, other controls limit the impact of an information security compromise, which we refer to as the principle of ‘defence in depth’.
- We ensure that access to, and configuration of, information assets is restricted to the minimum required to achieve business objectives, which we refer to as the principle of ‘least privilege’, which aims to reduce the number of attack vectors that can be used to compromise our information security.
- We ensure the timely detection of information security incidents. This minimises the impact of an information security compromise.
- We ensure information security is incorporated into the design of our information system assets, which we refer to as secure by design.
- We ensure that the use of, and access to, information assets is attributable to an individual, hardware or software, with activity logged and monitored.
- We ensure that error handling is designed such that errors do not allow unauthorised access to information assets or other information security compromises.
- We assume information assets have an unknown and possibly reduced level of information security control, which we refer to as the principle of ‘never trust, always identify’.
- We ensure that segregation of duties is enforced through the appropriate allocation of roles and responsibilities, which reduces the potential for the actions of a single individual to compromise our information security.
- We design controls that enforce compliance with our information security policy framework, thereby reducing reliance on individuals.
- We design detection and response controls based on the assumption that preventive controls have failed. This is typically referred to as the principle of ‘assumed breach’.
Awareness
- We have a training and information security awareness program to communicate to team members regarding information security practices, policies and other expectations.
- We track training undertaken and test the understanding of relevant information security policies on commencement and periodically.
- We educate our users about a) personal versus corporate use of information assets; b) email usage, internet usage (including social networking) and malware protection; c) physical protection, remote computing and usage of mobile devices; d) awareness of common attack techniques targeted at personnel and assets (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; and i) reporting of information security incidents and concerns.
Identity & Access
- We adopt identity and access management controls to ensure access to information assets is only granted where a valid business need exists, and only for as long as access is required.
- The factors we consider when authorising access to information assets include the business role, physical location, remote access, time and duration of access, patch and anti-malware status, software, operating system, device and method of connectivity.
- The provision of access to our users involves the following process stages: a) identification — determination of who or what is requesting access; b) authentication — confirmation of the purported identity; and 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.
- We put in place processes to ensure that identities and credentials are issued, managed, verified, revoked and audited for authorised devices, users and software/processes.
- The strength of identification and authentication is commensurate with the impact should an identity be falsified. Common techniques for increasing the strength of identification and authentication include using strong password techniques (i.e., length, complexity, re-use limitations and frequency of change), using 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; and c) is - for example, retinal scans, hand scans, signature scans, digital signature, voice scans or other biometrics.
- 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; and c) high-risk activities (e.g. third-party fund transfers, creation of new payees).
- We deploy the following access controls: a) undertake due diligence processes before granting access to personnel; 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); d) changing default passwords and usernames; 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; 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; k) generation, in preference to storage, of passwords/Personal Identification Numbers (PINs) where used to authorise high-risk activities; and l) two-person rule applied to information assets with the highest level of sensitivity rating (e.g. encryption keys, PIN generation, financial databases).
- For accountability purposes, we 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.
Software security
- We 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 Service), design and programming (for in-house developed software), testing and implementation.
- Ongoing security of existing software is considered as part of change management and as new vulnerabilities are identified. Typical factors we consider include: a) requirements — information security requirements are explicitly identified as part of the requirements definition of the software and address potential threats; b) design — considerations when designing secure software 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 are embodied in a set of standards and guidelines. Standards exist for each programming language, considering known vulnerabilities and what is considered good practice.
- We maintain a register of approved software development tools and associated usage. We 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 does not preclude the use of other tools in a non-production environment for the purposes of evaluation and experimentation.
- We implement roles, responsibilities and tools for managing the registration and deployment of source code to ensure that information security requirements are not compromised.
Cryptographic techniques
- Cryptographic techniques refer to methods used to encrypt data, confirm its authenticity or verify its integrity. The following are examples where we deploy cryptographic techniques given the risks involved: 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; and d) protection of partner and end-user PINs which are typically used for financial transaction authorisation.
- We select cryptographic techniques based on the activity's nature and the data's sensitivity and criticality. The cryptographic techniques would typically be reviewed on a regular basis to ensure that they remain commensurate with vulnerabilities and threats.
- We 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 attack impractical (i.e. would require an extremely long period of time to breach using current computing capabilities).
- 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 compromising the security of cryptographic keys. Any compromise of the security of cryptographic keys could, in turn, lead to a compromise the security of the information assets protected by the deployed cryptographic technique.
- We deploy, where relevant, controls to limit access to cryptographic keys, including a) use of physically and logically protected devices and environments to store and generate cryptographic keys, generate PINs and perform encryption and decryption. This involves the use of Hardware Security Modules (HSMs) or similarly secured devices; b) the 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 is commensurate with the risk; e) clearly defined cryptographic key revocation processes; and f) the deployment of detection techniques to identify any instances of cryptographic key substitution.
Partner security
- As a platform business, our technology can introduce additional information security vulnerabilities which, if exploited, could result in potentially material information security incidents impacting our partners and their customer beneficiaries. We implement preventative, detective and response controls commensurate with these risks. Common controls include: a) authentication controls commensurate with the vulnerability and threats associated with the products and services offered, which include the usage of a second channel notification/confirmation of events; 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); review of end-user 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; and 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.
Testing
- In order to limit access to what has been authorised based on job role and principle of least privilege, we adopt Identity & Access Management (IAM), user identification and authentication, physical security, employee awareness and training. We (for example) deploy social engineering tests in this regard.
- In order to authenticate users with the strength of authentication commensurate with the sensitivity of the information asset being accessed, we implement a password policy and system authentication controls. We perform audits of user access to test this objective.
- In order to protect networks from unauthorised network traffic, we use firewalls, routers, and network segmentation, and test these via penetration tests.
- In order to protect systems from malicious attacks, we deploy anti-malware, web and email filtering, with malware test samples, and configuration testing to test this objective.
- In order to protect system-to-system communication, including the exchange of data, from unauthorised access and use, we use encryption and key management, supported by a key management review
- In order for timely detection of unauthorised access and use, we use Logs, Security Information and Event Management (SIEM), integrity change detection solutions, event analysis and escalation procedures, and perform penetration tests to test our objective.
- In order to implement secure software, we adopt secure software development, software procurement and deployment practices. This objective is tested via design reviews, penetration tests, code review and scanning, network traffic analysis, fault testing, and fuzzing.
- In order to have effective and efficient responses to information security incidents, we adopt information security incident response playbooks, crisis management, and a Business Continuity Plan (BCP). We test this objective through tabletop exercises and public-private scenario tests.
- In order to have the resilience of systems to handle the failure of individual components, we adopt active-active, active-passive solutions deployed, sandboxed solutions, and zero trust architecture. We test for this objective via chaos monkey testing, architecture reviews, fault testing, and failover testing.
- In order to recover under all plausible scenarios, we adopt recovery plans and controls to protect backups from compromise. We perform technical recovery tests and backup environment penetration tests.
- In order to have implementation controls minimise the risk of new vulnerabilities from system change, our systems are secure by design. We adopt secure software development, non-functional testing, change control, and system hardening. We perform change control reviews, code scanning, architecture reviews, and fuzzing.
- In order to support timely identification and remediation of new vulnerabilities, we patch and use configuration management, supported by vulnerability scans, and penetration testing.
- In order to support the timely identification and remediation of new threats, we use threat intelligence, have an information security strategy, and periodically engage independent reviewers.
Reporting
- To socialise our capability, we report on Information security strategy, key initiatives and progress to date; Situational awareness analysis (including threat intelligence); Capability assessments (self-assessed or via benchmarking); and Identified capability gaps and status of remediation activities
- To communicate incidents, we: (a) Post-incident reports for material incidents; (b) perform incident trend analysis (internal and external); and (c) perform incident response test results (including simulations).
- To communicate controls, we report: (a) Control testing activities including schedule, scope, results and trends; (b) Internal audit activities including schedule, scope, results and trends); (c) Progress on risk and remediation activities; (d) Outcomes of vulnerability and threat assessments; (e) Third-party and related party assessments; and (f) Information security policy framework compliance reporting.
- To socialise the education of our teams, we report: (a) Informational and awareness material; and (b) Results of training and awareness sessions.
- To communicate events pre-compromise, we report on (a) External scanning blocked connections -count; (b) New vulnerabilities by OWASP type - count; (c) Malware stopped - count; (d) Phishing sites known - count; (e) Phishing site takedown - count, and hours open; (f) Unique malware targeting bank - count; (g) Vulnerabilities per line of code - count; (h) Applications going into production with code vulnerabilities - count; and (i) Security events detected -count.
- To communicate our practices pre-compromise, we report on (a) Penetration testing by type, count and finding rating, (b) Systems protected by identity and access management systems - count); (c) Internally developed systems that cannot be updated by type, and count); (d) Systems with out-of-vendor support components by type, count, and coverage %); (e) Systems without anti-malware solutions -count; (f) Non-authorised devices by type, and count); (g) Information security configuration compliance - coverage %; (h) Awareness exercises - coverage %, and count); (i) Staff responding to phishing tests - % of total staff; (j) User access review by role, privilege, ageing, and coverage %); (k) Security assessments of providers over twelve months - % coverage of relevant third parties; (l) Patch ageing by criticality, and days; and (m) Assurance report on information security - findings by rating, and ageing to remediation.
- To communicate our events on compromise, we report on (a) Detected malicious software endpoints - count; (b) Detected malicious software on servers - count; (c) Online directories containing staff/customer info - count; and (d) Incident type over the period - by type, and count.
- To communicate our practices on compromise, we report on (a) Response and recovery plans developed by type, count, and % coverage; and (b) Incident rehearsals by type, count, and % coverage).
- To communicate post-compromise events, we report on (a) Detected APT -count; (b) Blocked connections to malicious websites - count; (c) Data breaches detected - count; (d) Financial losses - $; and (e) Partner losses - $.
- To communicate post-compromise practices, we report on post-incident reports - count.