IT Security 001: MAS Technology Risk Management Guidelines (TRMG)

The Monetary Authority of Singapore (MAS) had published a set of Technology Risk Management Guidelines (TRMG) to help financial institutions address technology risks. Instead of finding the TRMG a nuisance, I felt that the guidelines are fantastic as they provide a starting point for an IT department begin addressing the technology risks that may go unnoticed if the department do not already possess the skills and expertise to address these concerns. Even if you are not a financial institution, I guess the TRMG is still relevant for you to benchmark your own risk management capabilities.

I attempt to create my own TL;DR version of the TRMG to capture the key principles and make it easier to remember for myself. Please only use this as a cheat sheet, and thoroughly review the Guidelines on your own if you are providing consultation or advice for your company.


1. Introduction

  1. IT is important to financial institutions (FI) business strategies.
  2. IT systems of FIs become more complex.
  3. FIs are offering more variety of IT services, therefore FIs should fully understand and manage the technology risks.
  4. TRMG consists of management principles and best practice to guide FIs in:
    • Establish a sound and robust technology risk management (TRM) framework.
    • Strengthening system security, reliability, resiliency, and recoverability.
    • Protect customer data, transactions and systems.
  5. TRMG is not legally binding, but MAS strongly encourage FIs to consider.

2. Applicability of the Guidelines

  1. FIs may adapt the TRMG where appropriate. TRMG should be applied in conjunction with relevant regulatory requirements and industry standards.
  2. TRMG objective is to promote sound practices and processes for managing technology.

3. Oversight of Technology Risks by Board of Directors (Board) and Senior Management (SM)

  1. Critical IT system failures can lead to reputational damage, regulatory breaches, revenue and business losses.
  2. Board and SM should have oversight of technology risks and ensure IT is capable of supporting business.
  3. Roles and Responsibilities
    1. Board and SM should ensure TRM framework is established and maintained. They should be involved in key IT decisions.
    2. Board and SM should ensure that controls and practices achieve security, reliability, resiliency and recoverability.
    3. Board and SM should consider cost-benefit issues (reputation, consequential impact, legal implications) when investing in controls and security measures for IT (systems, networks, datacentres, operations, and backups)
  4. IT Policies, Standards and Procedures
    1. FIs should establish policies, standards and procedures to manage risks and safeguard information system assets (data, systems, network device and other IT equipment).
    2. Policies, standards and procedures should be reviewed and updated regularly.
    3. Compliance process should verify that standards and procedures are enforced. Deviations should be addressed on a timely basis by a follow-up process.
  5. People Selection Process
    1. Have a screening process to carefully select staff, vendors and contractors to minimise technology risks due to system failure, internal sabotage or fraud.
    2. Staff, vendors and contractors authorised to access systems should be required to protect sensitive or confidential information.
  6. IT Security Awareness
    1. Establish a comprehensive security awareness training program for every staff. To include:
      • IT Security policies and standards
      • Individual responsibility
      • Measures to safeguard information system assets
      • Applicable laws, regulations and guidelines pertaining to usage, deployment and access to IT resources.
    2. Training program conducted and updated at least annually. Applicable to new and existing staff, contractors and vendors, accessing IT resources.
    3. SM to endorse training program. Content to be reviewed and updated to be relevant to emerging and evolving technology risks.

4. Technology Risk Management Framework

  1. TRM framework manage risks in a systematic and consistent manner. It encompasses:
    • Roles and responsibilities in managing technology risks.
    • Identification and prioritisation of information system assets.
    • Identification and assessment of impact and likelihood of current and emerging threats, risks and vulnerabilities.
    • Implementation of appropriate practices and controls to mitigate risks.
    • Periodic update and monitoring of risk assessment to include changes in systems, environmental or operating conditions that would affect risk analysis.
  2. Risk management practices and internal controls should be instituted to be effective.
  3. Information System Assets
    1. Assets should be adequately protected from unauthorised access, misuse, fraudulent modification, suppression or disclosure.
    2. FIs should establish clear policy on assets protection. Identify criticality of assets to develop protection plans.
  4. Risk Identification
    1. Entails determination of threats and vulnerabilities in the IT environment:
      • internal and external network
      • hardware and software
      • applications and systems interfaces
      • operations and human elements
    2. Threat may take any forms as long as it can cause harm by exploiting system vulnerabilities. Humans are significant sources of threats.
    3. FIs should be vigilant in monitoring mutating and growing risks e.g. ransomware outbreaks.
  5. Risk Assessment
    1. Analyse and quantify the business and operations impact of risks identified.
    2. Extent of impact depends on likelihood of threat and vulnerabilities occurring and causing harm.
    3. FIs should develop a threat and vulnerability matrix to assess potential impact and prioritise risks.
  6. Risk Treatment
    1. FIs should implement risk mitigation and control strategies for each type of risk identified. Measures should be consistent with the value of information system assets and level of risk tolerance.
    2. Risk mitigation entails a methodical approach for evaluating > prioritising > implementing risk control, which includes a combination of:
      • technical control
      • procedural control
      • operational control
      • functional control
    3. FIs should prioritise to address highest ranking risks given time and resources constraints. FIs should also consider their risk tolerance for damage and losses, and the cost benefit analysis (CBA) of implementing risk controls.
    4. FIs should maintain their business stability (costs effectiveness concerns) while managing and controlling risks.
    5. FIs should avoid implementing IT systems with unmanageable risks.
    6. FIs should consider taking insurance cover if applicable.
  7. Risk Monitoring and Reporting
    1. FIs should institute a monitoring and review process for continuous assessment and treatment of risks. FIs should maintain a risk register to:
      • Prioritise risks based on severity
      • Monitor risks closely
      • Report regularly on the mitigation actions
    2. FIs should use IT risk metrics (consider risk events, regulations, audit observations) to highlight systems, processes or infrastructure with highest risk exposure. Provide an overall technology risk profile to board and SM.
    3. FIs should review, evaluate, and update risk controls as IT environment changes to maintain effectiveness.
    4. Review and update of risk controls should also consider changing circumstances and risk profile of the FI.

5. Management of IT Outsourcing Risks

  1. There are many forms of IT outsourcing. May be single or multiple vendors, local or abroad.
  2. Due Diligence
    1. Board and SM should fully understand the risk of IT outsourcing. Determine the following before appointing outsource vendor:
      • viability, capability
      • reliability, track record
      • financial position
    2. FIs should ensure contractual T&C are fully covers all roles, relationships, obligations and responsibilities. Usually includes:
      • performance targets, service levels
      • availability, reliability, scalability
      • compliance, audit, security
      • contingency planning, disaster recovery (DR) capabilities
      • backup processing facilities
    3. FIs should ensure outsource service provider (as part of the contractual agreement) grant access to the FI or nominated parties and regulatory authorities without any hindrance:
      • to systems, operations, facilities and documentations
      • to review for regulatory, audit or compliance purpose
      • to inspect, supervise and examine service provider’s roles, responsibilities, obligations, functions, systems and facilities.
    4. Outsourcing should never weaken FI’s internal controls. FI should require service provider to employ high standard of care and diligence in:
      • Security policies, procedures, and controls
      • Protection of confidential and sensitive information (customer data, files, records, object programs and source codes).
    5. FIs should require service provider to implement the above controls as stringent as itself would.
    6. FIs should monitor and review the above controls regularly, and commission or obtain periodic expert reports on security adequacy and compliance w.r.t. the operations and services provided by the service provider.
    7. FIs should require service provider to have DR contingency framework (defines roles and responsibilities for documenting, maintaining and testing DR plans).
    8. Everyone concerned (including outsourced partners) should receive regular training in executing DR.
    9. DR plan should be reviewed, updated and tested regularly, according to changing environment.
    10. FIs should have contingency plan for viable alternatives to resume operations if service provider experience critical failure in a credible worst case scenario.
  3. Cloud Computing
    1. Cloud computing is a service and delivery model which users may not know the exact locations of IT resources in the service provider’s computing infrastructure.
    2. The same principle of due diligence applies to cloud computing. Note these unique attributes and risks:
      • data integrity
      • data sovereignty
      • data commingling
      • platform multi-tenancy
      • recoverability
      • confidentiality
      • regulatory compliance
      • auditing
      • data offshoring
    3. Considering multi-tenancy and data commingling architecture, FIs should ensure service provider is capable of isolating and identifying customer data and information system assets for protection.
    4. FIs should have contractual power and means to promptly remove or destroy data stored with service provider on contract termination.
    5. FIs should verify the service provider’s ability to recover within the stipulated RTO before outsourcing.

6. Acquisition and Development of Information Systems

  1. Many systems fail due to poor design, implementation and testing. FIs should identify defects and deficiencies in initial project phase.
  2. FIs should establish steering committee (business owners, developers, stakeholders) to oversee the project.
  3. IT Project Management
    1. Project management framework should include
      • Roles and responsibilities.
      • risk assessment and classification
      • critical success factors
      • milestones and deliverables
    2. FIs should document project plans that set out clear deliverables at each milestones.
    3. FIs should ensure that the following are approved by IT and Business:
      • functional requirements, system design, technical specs
      • business cases and CBA
      • test plans
      • service performance expectation
    4. FIs should establish management oversight to ensure timely completion. Issues cannot be solved by project committee should be escalated to SM.
  4. Security Requirements and Testing
    1. FIs should perform compliance checks on security standards against statutory requirements. Also, FIs should specify security requirements in early phase related to:
      • system access control, authentication
      • transaction authorisation
      • data integrity
      • system activity logging, audit trail, security event tracking
      • exception handling
    2. System testing methodology should be established to cover the following in various stress-load and recovery conditions:
      • business logic
      • security controls
      • system performance
    3. FIs should ensure full regression testing before system changes are made. Affected users should sign-off test results (refer to Appendix A).
    4. FIs should conduct penetration testing (pen-test) for new systems with internet accessibility and open network interface. Also perform vulnerability scanning of external and internal network components connected to the system.
    5. FIs should maintain separate environment for unit, integration, and UAT, and closely monitor vendor and developers access to these.
  5. Source Code Review
    1. Program code may conceal threats and loopholes which cannot be effectively identified through testing.
    2. Source code review is a methodical examination to find:
      • coding errors, poor coding practices, malicious codes
      • security vulnerabilities and deficiencies
      • mistakes in system design or functionality
    3. FIs should ensure high degree of system and data integrity for all systems. Ensure appropriate security control that considers complexity of applications.
    4. FIs should perform a combination of testing, source code reviews, and compliance reviews according to risk analysis.
  6. End User Development
    1. There are simple self-service applications for end users to do their own developments.
    2. FIs should assess the importance of such applications.
    3. Minimum recovery measures, user access and data protection controls should be implemented.
    4. FIs should test end user developed programs to ensure integrity and reliability.

7. IT Service Management

  1. IT service management framework supports:
    • IT systems, services, operations
    • change and incident management
    • stability of production environment
  2. Framework should include governance structure and processes and procedures for:
    • change management
    • software release management
    • incident management
    • capacity management
  3. Change Management
    1. Establish process to ensure production systems changes are assessed > approved > implemented > reveiwed.
    2. Process should apply to:
      • system and security configuration changes
      • patches for hardware devices
      • software updates
    3. Risk and impact analysis should be performed before deploying changes. Consider affected:
      • infrastructure, network
      • upstream and downstream systems
      • security implications
      • software compatibility
    4. Changes should be tested before deploying to production. Test plans should be documented. Tests results should be sign-off by users.
    5. Changes to production environment should only be approved by personnel with delegated authority.
    6. FIs should backup the systems and have a rollback plan prior to change. Should also have alternative recovery options if rollback is not possible after change.
    7. FIs should ensure logs are recorded for changes made.
  4. Program Migration
    1. Migration involves moving codes and scripts from development to test or production environment. Risks of malicious code injections.
    2. Each environment should be physically or logically separated.
    3. If controls in non-production environment is less stringent than production, FIs should perform risk assessment to ensure sufficient preventive and detective controls before migrating.
    4. Segregation of duties should be enforced to ensure no single individual can alone develop, compile and move objects across environments.
    5. Successful changes in production should also be replicated in DR system for consistency.
  5. Incident Management
    1. IT incident should be managed to avoid mishandling or aggravating of situation that prolong service disruption.
    2. FIs should establish incident management framework to restore IT services as quickly as possible following an incident, with minimal impact to business. Should include:
      • Roles and responsibilities
      • Recording of incidents
      • Analysing of incidents
      • Remediating of incidents
      • Monitoring of incidents
    3. FIs may delegate to a centralised technical helpdesk for assessing and assigning severity levels to incidents. Criteria of severity levels should be established and documented.
    4. Escalation and resolution procedures, and resolution timeframes should be appropriate to respective severity level.
    5.  Escalation and response plan should be tested on a regular basis.
    6. FIs should have an emergency response team made up of internal staff, with the technical and operational skills to handle major incidents.
    7. SM should be kept informed of incident developments in order to timely activate DR in case an incident aggravate into a crisis. Procedures to notify MAS when critical systems failed over to DR should be established.
    8. FIs should have predetermined action plan to address public relations issues, to maintain customer confidence throughout a crisis.
    9. FIs should keep customers informed of any major incident and consider effectiveness of communication (includes informing the general public).
    10. FIs should perform root-cause and impact analysis for major incidents and take remediation actions to prevent recurrence.
    11. FIs should have incident report that includes:
      • executive summary of incident
      • root-cause analysis
      • impact analysis
      • measures to address consequences of incident and the root cause
    12. Analysis should cover:
      1. Root Cause Analysis
        • when, where, why, and how the incident happened.
        • How frequent the incident occurred over last 3 years.
        • Lessons learnt from incident.
      2. Impact Analysis
        • Extent, duration, and scope of incident (include information of systems, resources, and customers affected).
        • Magnitude of incident (include foregone revenue, losses, costs, investments, number of customers affected, implications, consequences to reputation).
        • Breach of regulatory requirements.
      3. Corrective and Preventive Measures
        • Immediate corrective action to address consequence of incident (priority on addressing customers).
        • Measures to address root cause.
        • Measures to prevent similar future occurrence.
    13. FIs should address all incidents within corresponding resolution timeframes, and monitor all incidents to their resolution.
  6. Problem Management
    1. Problem management aim to determine and eliminate root cause to prevent occurrence of repeated problems.
    2. FIs should establish roles and responsibilities, and identify > classify > priorities > address problems in a timely manner.
    3. FIs should define criteria to categorise problems by severity level, and establish target resolution time and escalation processes for each severity levels.
    4. Trend analysis of past incidents will help with problem identification.
  7. Capacity Management
    1. FIs should ensure indicators for systems and infrastructure such as performance, capacity, and utilisation are monitored and reviewed.
    2. FIs should establish monitoring processes and appropriate threshold to be able to cater additional resources in a timely manner.

8. Systems Reliability, Availability and Recoverability

  1. This is important as critical system failures can lead to widespread and disruptive impact, affecting reputation and confidence.
  2. FIs should define recovery and business resumption prioritities, test and practise its contingency procedures.
  3. System Availability
    1. Important factors are:
      • adequate capacity
      • reliable performance
      • fast response time
      • scalability
      • swift recovery capability
    2. FIs should develop built-in redundancies to reduce single point of failure. Should maintain standby hardware, software and network components for fast recovery.
    3. FIs should achieve high availability for critical systems.
      • High availability = Other than planned maintenance, downtime should be minimised with suitable resiliency solutions.
      • Critical system = system which will lead to significant impact to operations or customers if failed.
  4. Disaster Recovery Plan
    1. Recovery plan should include scenario analysis for contingency scenarios such as major system outages, hardware malfunction, operating errors, security incidents, and failure of primary DC.
    2. FIs should review and update recovery plan and incident response procedures at least annually or when there are operations, systems or network changes.
    3. FIs should implement rapid backup and recovery capabilities at individual system or application cluster level, considering inter-dependencies when creating recovery plan and contingency tests.
    4. FIs should define recovery and business resumption priorities with specific RTO and RPO.
      • RTO = time to restore a system disruption.
      • RPO = acceptable amount of data loss.
    5. FIs should establish a geographically separated recovery site to restore critical systems and resume business operations when primary site fails.
    6. Recovery speed requirements depend on criticality and available alternatives. FIs may explore on-site redundancy and real-time data replication to enhance recovery capability.
    7. For critical systems outsourced to offshore service providers, FIs should consider cross-border network redundancy, engaging multiple network providers, and alternate network path to enhance resiliency.
  5. Disaster Recovery Testing
    1. FIs should refrain from adopting impromptu and untested recovery measures during system outage, as they carry high operational risks without validating effectiveness.
    2. FIs should test the effectiveness of recovery requirements and ability of staff to execute the procedures at least annually.
    3. DR tests should cover various scenarios like total shutdown, primary site failure, and individual component failure.
    4. FIs should conduct bilateral or multilateral recovery testing for systems or networks linked to specific service providers.
    5. FIs should involve business users in designing test cases to verify recovered systems. FIs should also participate in DR tests conducted by its service providers.
  6. Data Backup Management
    1. FIs should develop data backup strategy for storage of critical information.
    2. FIs may implement DAS, NAS, or SAN as part of the data backup and recovery strategy. Processes should be in place to review storage architecture, connectivity, and technical support by service providers (refer to Appendix B).
    3. FIs should carry out periodic testing of backup media and assess if media is adequate and effective in supporting recovery processes.
    4. FIs should encrypt backup media (including USB disks) containing sensitive information before transporting to offsite storage.

9. Operational Infrastructure Security Management

  1. FIs should implement security solutions at data, application, DB, OS, and network layers to adequately address potential cyber attacks.
    • Cyber Attacks = phishing, DOS, spam, sniffing, spoofing, hacking, key-logging, MITM, malware.
  2. FIs should have appropriate measures to protect sensitive and confidential information (personal, account, transaction data). Customers should properly authenticate before accessing data. Secure data against exploits like ATM skimming, card cloning, hacking, phishing and malware.
  3. Data Loss Prevention
    1. Insider attacks (from current and ex-staff, vendors and contractors) are among the most serious risks. FIs should adopt adequate measures to detect and prevent unauthorised access, copy, or transmission of important and confidential data.
    2. FIs should have comprehensive data loss prevention strategy that considers:
      • Data at endpoint – notebooks, PC, portable storage, mobile.
      • Data in motion – across network, or transport across sites.
      • Data at rest – files, DB, backup media, storage.
    3. FIs should address risks of data theft, data loss and data leakage from endpoints. Confidential information should be stored with strong encryption.
    4. FIs should not use unsafe internet services to exchange confidential information, and implement measures to detect and prevent the use of such services.
    5. For exchanging confidential information with external parties, FIs should employ strong encryption with adequate key length, and send the encryption key in separate transmission channel. May also use other secure methods.
    6. Confidential information stored on IT systems should be encrypted with strong access controls and principle of “least privilege”.
      • least privilege = “need-to-have” basis.
    7. FIs should determine the appropriate media sanitisation method, depending of security requirement of data, to prevent loss of confidential information through disposal of IT systems.
  4. Technology Refresh Management
    1. FIs should maintain up-to-date inventory of software and hardware used in production and DR environments, including relevant warranty and support contracts.
    2. FIs should actively replace outdated and unsupported systems, as EOS products cease to have security patches for vulnerabilities.
    3. FIs should establish technology refresh plan to ensure that systems and software are replaced in a timely manner. Conduct risk assessment and risk mitigation for continued usage of systems approaching EOS.
  5. Network and Security Configuration Management
    1. FIs should configure systems and devices with expected level of security. Establish baseline standards to facilitate consistent security configurations across OS, DB, network devices and enterprise mobile.
    2. FIs should conduct regular enforcement review to ensure baseline standards are applied, with frequency of review which commensurate with the level of risks.
    3. FIs should apply anti-virus to servers. Update anti-virus definition files regularly and schedule automatic scans.
    4. FIs should install network security devices (firewalls, IDS, IPS) at critical infrastructure juncture to protect network perimeter. Deploy internal firewalls or similar measure to minimise security exposure to both internal and external network. Regularly backup and review network security rules to remain appropriate and relevant.
    5. FIs deploying WLAN should be aware of the risks and implement measures to secure network from unauthorised access.
  6. Vulnerability Assessment (VA) and Penetration Testing
    1. VA is the process to discover > identify > assess security vulnerabilities in a system. FIs should conduct VA regularly.
    2. FIs should deploy a combination of automated tools and manual techniques to perform comprehensive VA (include common web vulnerabilities for VA on web-based external facing system).
    3. FIs should establish process to remedy issues identified in VAs, and validate the success.
    4. FIs should conduct pen-test through simulating actual attacks to evaluate security posture of system. Pen-test on internet-facing system at least annually.
  7. Patch Management
    1. FIs should establish patch management procedures that identify > categorise > priorities security patches, and have implementation timeframe for each category.
    2. FIs should test security patches rigorously before deploying to production.
  8. Security Monitoring
    1. FIs should establish security monitoring systems and processes to promptly detect unauthorised or malicious activities by external and internal parties.
    2. FIs should implement network surveillance and security monitoring procedures with network security devices to be alerted of intrusions.
    3. FIs should implement security monitoring tools which detects changes to critical IT resources, to identify unauthorised changes.
    4. FIs should perform real-time monitoring of security events for critical systems.
    5. FIs should regularly review security logs of systems, applications and network devices for anomalies.
    6. FIs should adequately protect and retain system logs for future investigations. Retention period should consider statutory requirements.

10. Data Centres Protection and Controls

  1. It is important for DC to be resilient and physically secured.
  2. Threat and Vulnerability Risk Assessment (TVRA)
    1. TVRA identify security threats and operational weakness in a DC to determine the level and type of protection to be established.
    2. TVRA should consider various scenarios (theft, explosives, arson, unauthorised entry, external attacks, insider sabotage) and various factors:
      • criticality of DC
      • geographical location
      • multi-tenancy and type of tenants in DC
      • impact of natural disaster
      • political and economic climate of country
    3. TVRA scope should include:
      • review of DC’s perimeter and surrounding
      • building and facility, critical mechanical and engineering system
      • building and structural elements
      • daily security procedures
      • physical, operational, and logical access control
    4. FIs should obtain TVRA of provider DC, verify that report is current and provider is committed to address vulnerabilities identified, before selecting DC. TVRA should be performed during feasibility study when building FI’s own DC.
  3. Physical Security
    1. FIs should limit DC access to authorised staff only (principle of least privilege).
    2. FIs should ensure temporary access for non-DC personnel are properly notified, approved, and accompanied by authorised employee.
    3. FIs should ensure DC is physically secured and monitored, employing physical, human, and procedural controls where appropriate (security guards, card access systems, mantraps, bollards).
    4. FIs should deploy security systems and surveillance tools to monitor and record activities within DC. Have physical security measures to prevent unauthorised access to systems, equipment racks and tapes.
  4. Data Centre Resiliency
    1. FIs should assess redundancy and fault tolerance in:
      • electrical power
      • air-conditioning
      • fire suppression
      • data communications
    2. FIs should monitor and regulate environment within DC such as temperature and humidity. Escalate to management and resolve abnormalities detected in a timely manner.
    3. FIs should implement appropriate fire protection and suppression systems to control full scale fire. Includes:
      • smoke detectors
      • hand-held fire extinguishers
      • passive fire protection (e.g. fire wall)
    4. FIs should install backup power consisting:
      • uninterrupted power supplies
      • battery arrays
      • diesel generators

11. Access Control

  1. Three of the most basic internal security principles for protecting systems:
    • Never alone principle = critical systems functions and procedures are carried out by more than one person or at least checked by another person. Includes critical systems initialisation and configuration, PIN generation, creation of cryptographic keys, use of admin accounts.
    • Segregation of duties principle = design transaction processes so that no single person may initiate, approve, execute, and enter transactions into a system for fraud. Job rotation for security administration. Responsibilities for the following should be performed by separate groups:
      • OS functions
      • systems design and development
      • application maintenance
      • access control administration
      • data security
      • librarian and backup data file custody
    • Access control principle = only grant access rights on principle of least privilege, regardless of rank or position. Only provide authorisation for legitimate purposes.
  2. User Access Management
    1. FIs should only grant access on need-to-use basis and within required period. Ensure that resource owner authorise and approve the access.
    2. External parties given access to critical systems should be subjected to close supervision, monitoring, access restrictions similar to internal staff.
    3. FIs should ensure user access are uniquely identified and logged for audit and review purposes.
    4. FIs should regularly review user access privileges to verify that privilege is appropriate, and identify dormant or wrongly provisioned accounts.
    5. FIs should enforce strong password controls that include:
      • change of password on first logon
      • minimum password length and history
      • password complexity
      • maximum validity period
    6. FIs should ensure no one has concurrent access to production and backup systems, and access to backup systems should only be for specific reason and period.
  3. Privileged Access Management
    1. FIs should apply stringent selection criteria and thorough screening when appointing staff for critical operations and security functions.
    2. These staff (system admin, security officers, programmers) are capable of severely damaging critical systems by virtue of their privilege access.
    3. FIs should closely supervise these staff, log and review their system activities, and adopt the following controls and security practices:
      • strong authentication mechanism (e.g. 2FA).
      • strong control over remote access.
      • restrict number of privilege users.
      • Grant privilege access on “need-to-have” basis.
      • Maintain audit logging of system activities.
      • Disallow privilege user access to logs of systems they are accessing.
      • Review activities on a timely basis.
      • Prohibit sharing of accounts.
      • Disallow vendors and contractors privilege access without close supervision.
      • Protect backup data from unauthorised access.

12. Online Financial Services

(Refers to provision of banking, trading, insurance, other financial services and products via electronic delivery channels)

  1. FIs should recognise the risk of offering services via internet platform.
  2. Varying degree of risks are associated with different types of services:
    • information service
    • interactive information exchange service
    • transactional service (highest risk due to irrevocable execution)
  3. FIs’ risk management process should clearly identify the risks and formulate security controls, system availability, and recovery capabilities which commensurate with the level of risks.
  4. Online Systems Security
    1. FIs should devise security strategy to ensure confidentiality, integrity, and availability of data and systems.
    2. FIs should assure customers that online services are adequately protected and authenticated.
    3. MAS expects FIs to properly evaluate security requirements associated with internet systems and adopt well-established international encryption standards (refer to Appendix C).
    4. FIs should ensure information processed, stored, or transmitted are accurate, reliable and complete, by implementing physical and logical access security, processing and transmission controls.
    5. FIs should implement monitoring or surveillance system to be alerted of abnormal system activities, transmission errors, or unusual transactions, and have follow-up process to verify the issues are addressed.
    6. FIs should maintain high resiliency and availability, put in place measures to plan and track capacity utilisation and guard against online attacks (refer to Appendix D).
    7. FIs should implement 2FA login and transaction-signing. These secure authentication process, protect data integrity, and enhance customer confidence.
    8. For systems serving institutional investors, accredited investors or corporate entities, using alternate controls and processes to authorise transactions, FIs should perform risk assessment to ensure security level is at least as adequate as token-based mechanisms.
    9. FIs should take appropriate measures to minimise exposure to other cyber attacks such as MITM, MITBrowser, MITApplication (refer to Appendix E).
    10. FIs should implement measures to protect customers, educate them on the measures put in place, and ensure they have access to continual education to raise security awareness (refer to Appendix F).
  5. Mobile Online Services and Payments Security
    1. Mobile Online Services refers to provision of financial services via mobile devices, either through web browser or FI’s self-developed applications on mobile platforms (Apple iOS, Google Android, Microsoft Windows OS).
    2. Mobile Payment refers to use of mobile devices to make payments, which may use various technologies (e.g. NFC).
    3. Both are extensions of online financial services. FIs should implement similar security measures as online financial services, conduct risk assessment and implement appropriate measures to counteract payment card fraud on mobile devices.
    4. FIs should ensure protection of sensitive or confidential information as mobile devices are susceptible to theft and loss. Implement encryption to secure data in storage and transmission, and ensure processing are done in secure environment.
    5. FIs should educate customers on security measures to protect their own mobile devices from malware.

13. Payment Card Security (Automated Teller Machines, Credit and Debit Cards)

  1. Payment cards allows physical purchase, online purchase (and over mail-order or over telephone) and ATM cash withdrawals.
  2. There are many forms of payment cards. Magnetic stripe cards are vulnerable to skimming attacks, which can take place during payment card processing (at ATMs, payment kiosk, EFTPOS terminals).
  3. Payment card frauds include:
    • counterfeit
    • lost or stolen
    • card-not-received (CNR)
    • card-not-present (CNP)
  4. Payment Card Fraud
    1. FIs offering payment card service should protect sensitive data. Implement encryption to secure data in storage and transmission, and ensure processing are done in secure environment.
    2. FIs should use secure chips to store sensitive data and implement strong authentication methods such as dynamic data authentication (DDA) or combined data authentication (CDA). Should not use magnetic stripe to store sensitive data. If interoperability concerns require the use of magnetic stripe for transactions, ensure adequate control measures are implemented.
    3. For transactions using ATM cards, FIs should perform authentication of sensitive customer information (not third party service provider). FIs should perform regular security reviews on infrastructure and processes used by service providers.
    4. FIs should ensure security controls on payment card systems and network.
    5. FIs should only activate new payment cards upon obtaining customer’s instruction.
    6. FIs should implement dynamic OTP for CNP transactions via internet to reduce risk.
    7. FIs should promptly notify cardholders when withdrawals or charges exceeding customer-defined threshold is made. Alert should include transaction source and amount.
    8. FIs should implement robust fraud detection systems with behavioural scoring or equivalent, and correlation capabilities. FIs should set out risk management parameters according to risk posed by cardholders, nature of transactions or other risk factors.
    9. FIs should investigate transactions that deviates significantly from cardholder’s usual usage patterns and obtain cardholder’s authorisation before completing transactions.
  5. ATMs and Payment Kiosk Security
    1. ATMs and payment kiosks (e.g. SAM and AXS) are targets of card skimming attacks.
    2. FIs should consider the following measure to secure consumer confidence in using these systems:
      • anti-skimming solutions to detect foreign devices placed over or near card entry slot.
      • detection mechanism that sends alerts to FI staff for follow-up responses and actions.
      • tamper-resistant keypads to ensure customers’ PIN are encrypted during transmission.
      • appropriate measures to prevent shoulder surfing of customers’ PINs.
      • Video surveillance of activities at the machines and maintain quality CCTV footage.
    3. Verify adequate physical security are implemented in third party payment kiosks which accept and process FI’s payment cards.

14. IT Audit

  1. FIs need to develop effective internal control systems to manage technology risks.
  2. IT audit provides Board and SM independent and objective assessment of the effectiveness of controls to manage technology risks.
  3. FIs should establish organisational structure and reporting lines for IT audit in a way that preserves the independence and objectivity.
  4. Audit Planning and Remediation Tracking
    1. FIs should ensure IT audit scope is comprehensive and includes all critical systems.
    2. IT audit plan comprising auditable IT areas for the coming year should be developed, and approved by the FI’s Audit Committee.
    3. FIs should establish audit cycle and determine the frequency of IT audit that commensurate with criticality and risk of IT system or process.
    4. Follow-up process to track and monitor IT audit issues, and escalation process to notify IT and business management of key issues should be established.

 


 

I will be publishing appendix A-F of the TRMG in a separate blog post.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s