IT Security 002: MAS TRMG Appendix

Continuing from the previous post, this is a summary of Appendix A-F of MAS Technology Risk Management Guidelines (TRMG).

The appendix provides more details for some of the specifications mentioned in the main body of the guidelines, and may tend to be a little bit more technical.


Appendix A: System Security Testing and Source Code Review

  1. Security testing alone is ineffective in detecting all threats and weaknesses. FIs should also include system source code review in its System Development Life Cycle (SDLC).
  2. FIs should take note of the following during system testing and source code review:
    • Information Leakage – scrutinise the potential sources of sensitive information leakages through verbose error messages, hard-coded data, files and directories operations.
    • Resiliency Against Input Manipulation – Lack of proper input validation can spawn major vulnerabilities such as script injection and buffer overflows. Validation routines should be reviewed and tested to assess effectiveness. Validation should include:
      • validate all inputs to an application.
      • validate all forms of data input format.
      • verify the handling of null or incorrect inputs.
      • verify content formatting.
      • validate maximum length of input.
    • Unsafe Programming Practices – review the source code to identify unsafe practices:
      • vulnerable function calls.
      • poor memory management.
      • unchecked argument passing.
      • inadequate logging and comments.
      • use of relative paths.
      • logging of authentication credentials.
      • assigning inappropriate access privilege.
    • Deviation From Design Specifications – test critical modules (such as authentication functions and session management) to ensure no deviation. Include:
      • verify security requirements (credential expiry, revocation, reuse) and protection of cryptographic keys for authentication.
      • verify sensitive information stored in cookies are encrypted.
      • verify session identifier is random and unique.
      • verify session expires after a pre-defined length of time.
    • Cryptographic Functions – strength of cryptography depends on algorithm, key size, and implementation. Consider:
      • implement cryptographic modules based on authoritative standards and reputable protocol.
      • review algorithms and key configurations for deficiencies and loopholes.
      • assess the choice of ciphers, key sizes, key exchange protocols, hashing functions, RNG.
      • testing all cryptographic operations and key management procedures.
      • (refer to Appendix C).
    • Exception Handling – ensure robust exception and error handling that facilitates fail-safe processing, assist problem diagnosis through logging, and prevent leakage of sensitive information.
    • Business Logic – ensure that business logic are tested and deny unauthorised function or transaction. Consider the use of negative testing.
    • Authorisation – perform tests to ensure actual access rights granted conform to the approved security access matrix.
    • Logging – ensure the following when implementing logging functions:
      • sensitive information should not be logged.
      • maximum data length for logging is pre-determined.
      • logs both successful and unsuccessful authentication.
      • logs both successful and unsuccessful authorisation.

Appendix B: Storage System Resiliency

  1. Overview
    1. Resiliency and availability of storage systems are crucial to continuous operation of critical applications.
  2. Reliability and Resiliency
    1. FIs should review storage system architecture and connectivity regularly (both centralised and distributed storage). Prevent single points of failure and fragile functional design, ensure technical support.
    2. Poorly designed SANs concentrate risks to system infrastructure. FIs should ensure redundancy of all SAN components (multiple links and switches for all I/O operations between hosts, adapters, storage processors and storage arrays), and a HA, resilient, and flexible architecture.
    3. FIs should establish sound patch management process for timely update of storage systems, and rigorous change management process for deploying of configuration changes and upgrades.
    4. FIs should establish in-house alert and monitoring capability for early detection of storage systems outages. Consider data replication mechanisms and vendor call-home capability for enhanced resiliency. Should also maintain oversight of diagnostics and remediation activities.
  3. Recoverability
    1. FIs should ensure architecture of storage system is able to switch from primary production to alternate site to meet expected RTO and RPO. Should regularly test the recoverability and data consistency at alternate site.

Appendix C: Cryptography

  1. Principles of Cryptography
    1. Primary purpose is to protect integrity and privacy of sensitive information.
    2. Secrecy of the key is important, not the secrecy of algorithm. Ensure protection and secrecy of all keys used (master keys, key encrypting keys, data encrypting keys).
  2. Cryptographic Algorithm and Protocol
    1. Cipher algorithms may need to be enhanced or replaced in the face of ever improving computer hardware and techniques enabling the attacks on cryptography.
    2. FIs should review algorithms and key configurations for deficiencies and loopholes, and assess the choice of ciphers, key sizes, key exchange protocols, hashing functions, RNG.
    3. FIs should ensure RNG has sufficient size and randomness of seed number to preclude the possibility of optimised brute force attack.
  3. Cryptographic Key Management
    1. FIs should establish key management policy and procedures that covers generation > distribution > installation > renewal > revocation > expiry.
    2. FIs should ensure the keys are securely generated, such that constituents are destroyed or no single person has access to the entire key or all constituents. Ensure that keys are created > stored > distributed > changed under stringent conditions.
    3. FIs should ensure unencrypted symmetric keys are entered into tamper-resistant devices (e.g. HSM) using principles of dual control. Keys should only be used for single purpose to reduce exposure.
    4. FIs should decide the appropriate effective timeframe (cryptoperiod) of keys, using sensitivity of data and operational criticality to determine frequency of key changes.
    5. FIs should ensure HSM and keying materials are physically and logically protected.
    6. FIs should ensure keys are not exposed during usage or transmission.
    7. FIs should use secure key destruction method on expired key to prevent recovery by any parties.
    8. New keys should be generated independently from the previous keys.
    9. FIs should maintain a backup of keys, with same level of protection accorded to the original keys.
    10. FIs should immediately revoke > destroy > replace any compromised keys, as well as all derived keys or encrypted keys affected. Inform all parties concerned of the revocation.

Appendix D: Distributed Denial-Of-Service Protection

  1. Overview
    1. Proliferation of botnets and new attack vectors have increased the potency of DDOS attacks.
    2. Evolving threat landscape allows more sophisticated DDOS attack on other layers of OSI with minimal bandwidth.
    3. DDOS attack would cripple the network and system of even large commercial organisations, causing massive service disruption or cessation.
    4. In spite of malware protection, FIs should still bolster the system robustness against DDOS attacks.
  2. Detecting and Responding to DDOS Attacks
    1. FIs should deploy appropriate tools to detect, monitor, analyse anomalies in networks and systems (unusual traffic, volatile system performance, sudden surge in utilisation) and have anti-DDOS equipment to respond to DDOS attacks.
    2. On top of network perimeter security devices that alert FIs of suspected attacks, consider using purpose-built high performance appliances to handle DDOS so that legitimate traffic is still allowed as malicious packets are filtered.
    3. Elimination of single source of failure vulnerable to DDOS attacks should be eliminated through source code review, network design analysis, and configuration testing.
  3. Selection of Internet Service Providers
    1. Effective countermeasure to DDOS often rely on ISPs to dampen attacks in upstream network.
    2. FIs should incorporate DDOS attack considerations when selecting ISP and determine:
      • whether ISP offers DDOS protection or clean pipe services.
      • the ability of ISP to scale up network bandwidth on demand.
      • the adequacy of ISP’s incident response plan.
      • capability and readiness of ISP to respond quickly to attacks.
  4. Incident Response Planning
    1. FIs should devise incident response framework and routinely validate it to facilitate fast response to DDOS attacks. Include:
      • detailed immediate steps to counter an attack.
      • invoke escalation procedures.
      • activate service continuity arrangements.
      • trigger customer alerts.
      • reporting the attack to MAS.
    2. FIs should assimilate ISP incident response plans into their own, establish a communication protocol with the ISP and conduct periodic joint incident response exercises.

Appendix E: Security Measures for Online Systems

  1. Overview
    1. MITM attack = an interloper accessing and modifying communications between two parties without revealing that the link has been compromised.
    2. There are many possible MITM attacks (on computing devices, internal networks, information service providers, web servers, anywhere along the path between user and FI’s server).
  2. Security Measures
    1. FIs should implement adequate controls and measures to prevent MITM as part of 2FA infrastructure.
    2. For high-risk transactions, consider:
      • use digital signatures and key-based message authentication codes (KMAC) to prevent MITM.
      • ensure customer is able to distinguish generation of OTP from hardware token and the process of signing a transaction.
      • use different cryptographic keys for generating OTP and for signing.
    3. FIs may choose to implement challenge-based or time-based OTP. Time-based OTP validity window should be configured on server side, and be as short as practicable to lower risks.
    4. Customers should be notified through a second channel of high-risk transactions, with meaningful information of the transaction. The notification should not be sent to the same device performing the transaction.
    5. FIs should implement end-to-end encryption security at application layer to protect customer PINs and password, on top of SSL.
    6. Online sessions should automatically terminate after a fixed period unless customer re-authenticate.
    7. FIs should educate customers to terminate login session when facing wrong SSL server certificate warning, and notify the FI immediately.

Appendix F: Customer Protection and Education

  1. Overview
    1. FIs should protect customers’ accounts and data, and raise customers’ security awareness with regard to online financial services.
  2. Customer Protection
    1. FIs should not distribute software to customers via the internet unless there are adequate security and safeguards. There should be appropriate alert and assistance for the customer to verify the origin and integrity of those downloads.
    2. Observe the following controls when handling customers’ login credentials:
      • implement dual control and segregation of duties in password generation, dissemination and account activation.
      • print password mailer in secure location where access is restricted and monitored.
      • destroy mailer spoilages immediately and generate a new password for each reprint.
      • destroy all stationary that may contain password imprint during mailer printing.
      • ensure passwords are not exposed or compromised during dissemination process.
      • ensure passwords are not processed, transmitted, stored in clear text.
      • require customers to change passwords immediately upon first login.
      • only distribute hardware token that has been assigned to a customer account.
    3. FIs should inform customers about risks and benefits, terms and conditions, rights, obligations and responsibilities of all parties (in particular regarding processing errors and security breaches) before customer subscribe to the service, in an easy to understand format.
    4. FIs should make the terms and conditions readily available to the customers and require a positive acknowledgement on initial logon or subscription.
    5. FIs should post these disclosures on its website:
      • customer privacy and security policy
      • customer dispute handling, reporting, and resolution procedures, including expected response time. Explain the process to resolve problems or disputes,  and circumstances which losses would be attributable to FI or the customers if security breaches occur.
      • security measures and reasonable precautions customers should take when accessing their online accounts (prevent unauthorised transactions, fraud, stealing of credentials, impersonation).
    6. FIs should ensure that any interference to an authenticated session will result in session termination, and affected transactions are resolved or reversed out. Promptly notify the customer of such incident.
  3. Customer Education
    1. FIs should educate the customers on the security and reliability of their interaction with FIs. It will build customer confidence, and customer will understand the appropriate security measure they should take to safeguard their own devices.
    2. FIs should provide sufficient instruction and information to customers on new operating features and functions. Continual education and timely information will help customers in reporting security problems.
    3. FIs should remind customers on the need to protect their authentication information. FIs may display security instructions on login pages. Consider the following guidelines:
      • PIN should be at least 6 digits or alphanumeric characters.
      • PIN should not be based on guessable personal information.
      • PIN should be kept confidential.
      • PIN should be memorised and not recorded anywhere.
      • PIN should be changed regularly when there is any suspicion of compromise or impairment.
      • Same PIN should not be used for multiple applications.
      • Customer should not allow browser to store or retain usernames and passwords.
      • Customer should check authenticity of FI’s website by validating the URL and digital certificate information (SSL EV certifications).
      • Customers should check that secure HTTP and security icon appears in browser when authentication and encryption is expected on the website.
      • Customer should not allow anyone to tamper with their OTP token.
      • Customer should not reveal the OTP generated from their token.
      • Customer should not divulge the serial number of their OTP token.
      • Customer should check their account information, balance and transactions frequently and report any discrepancies.
      • Customer should inform FI immediately on the loss of their mobile phones, or changes in phone numbers.
    4. FIs should advise customers to adopt the following security precautions and practices:
      • install anti-virus, anti-spyware, and firewall software on their personal devices.
      • update OS and protection software regularly.
      • remove file and printer sharing in computers, especially when connected to internet.
      • regularly backup critical data.
      • consider encryption technology to protect highly sensitive information.
      • log off at the end of online sessions.
      • clear browser cache after online sessions.
      • do not install software or run programs of unknown origins.
      • delete junk or chain emails.
      • do not open email attachments from strangers.
      • do not disclose personal or financial information to little-known or suspicious website.
      • do not use a device that cannot be trusted.
      • do not use public internet or devices to access online services or perform financial transactions.
    5. FIs should educate customers on the features of payment cards and the associated risks, the security features and steps to report card loss or fraud cases.
    6. The above information are not intended to be static or exhaustive. FIs should provide updated security practices and guidelines to customers in a user-friendly manner.

 

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