0% found this document useful (0 votes)
46 views69 pages

Security Risk Management Modelv1

Uploaded by

Seph Lwl
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
46 views69 pages

Security Risk Management Modelv1

Uploaded by

Seph Lwl
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Security Risk

Management Models
Saravanan Kulanthaivelu

Security Risk Management Models 0


Biography

• Currently employed as Cyber Forensic Senior Specialist for Standard Chartered Global Business
Service
• more than 18 years of experience in the IT industry, with experience in forensics, incident response,
network security, malware analysis and threat intelligence.
• Worked as consultant with Mandiant (FireEye) and was stationed in one of the largest bank in
Malaysia as resident incident response and forensic consultant, providing global threats advisory
services.
• Worked in the law enforcement sector, Malaysian Communication and Multimedia Commission
(MCMC) which monitors threats towards Malaysian network and advise the relevant bodies on
mitigation strategies.
• Master in Science, Universiti Sains Malaysia.
• Bachelor in Computer Science with Honors, Universiti Sains Malaysia.
• Member of
• HTCIA
• GIAC Advisory Board
• UKM Fellow
• Certifications

Security Risk Management Models 1


Contents

1. Introduction
2. RMIT-BNM
3. MAS –Managing Technology Risk
4. ISO 31000 standards for Enterprise Risk Management

Security Risk Management Models 2


Risk Management

• We have choices on how to deal with the risks we identify. Anyone familiar with the discipline
of risk management is familiar with these:
-We can accept a risk and do nothing. This is a calculated decision that the
probability of occurrence and the potential loss do not warrant action.
-We can insure against it. This is a backstop to the potential loss, transferring a
portion of the financial impact to another party.
-We can transfer a risk to another entity. If an organization is savvy enough to assign
risk ownership, this is a strong option to place risk where it can best addressed,
resourced, etc.
-We can mitigate a risk. Take steps to make the occurrence of the risk as painless as
possible, or avoid it altogether.

Security Risk Management Models 3


Technological Risks –Monitoring and Managing

• Year after year, new technologies revolutionize how we do business, offering incredible benefits
to organizations, but reliance on technology also increases risk exposure.
• When technology fails, the business disruption can result in revenue loss and damaged
consumer confidence. Whether a customer’s data is stolen, electrical outages at an overseas
plant occurs or there is simply a lack of technology in an emerging nation, technological risks
can be incredibly damaging.
• Without an effective technology risk management strategy, organization’s profitability and
reputation could be impacted.

Security Risk Management Models 4


Damaging Technological Risk-Example

• In 2017 data breach involving Equifax, a credit


reporting agency, private information of as many
as 143 million people was stolen. The impact
was not only significant in numbers, but
significant as far as the value of the information
goes. Names, addresses, social security numbers
and birth dates were accessed by the hackers.
And worse, it took Equifax 6 weeks to notify
customers.
• Weeks following, the CEO of Equifax stepped
down from his position. Dozens of lawsuits were
filed against Equifax. Because the company
failed to secure the sensitive data of its
customers, it now faces not only the financial
damage from the lawsuits, but also incredible
reputational damage that will be hard to recover
from.

https://investorplace.com/2019/03/equifax-stock-investors-are-
Security Risk Management Models 5
still-paying-for-2017-data-breach/
Risk Management In Technology (RMiT) -Draft

• Bank Negara Malaysia (the Malaysian Central Bank) (BNM) had, on 4 September 2018, issued an
exposure draft of the Risk Management in Technology policy document (RMiT Exposure Draft)
• BNM is proposing for the policy to come into force on 1 June 2019 and it will apply to licensed
banks,3 licensed insurers, licensed takaful operators, prescribed development financial
institutions, operators of a designated payment system and eligible issuers of e-money
(collectively, FIs).
• Minimum standards on technology risk and cyber security management by FIs in Malaysia
• If finalized, there will begin to be some (but not complete) alignment by BNM and the Monetary
Authority of Singapore (MAS) on managing technology risk.

Security Risk Management Models 6


RMiT-Board and Senior Management Responsibilities

• The board of directors of FIs (Board) will have overall responsibility and oversight for the
implementation of a robust technology risk management framework.
• The Board is required to, among others, put in place a technology risk management framework
(i.e., a framework for safeguarding the FI's information infrastructure, systems and data) (TRMF)
and a cyber resilience framework (i.e., a framework for ensuring the FI's financial resilience)
(CRF).
• The senior management of FIs are tasked with implementing the TRMF and CRF through specific
policies and procedures.
• Stricter requirements are imposed on large FIs under the RMiT Exposure Draft.

Security Risk Management Models 7


RMiT-Chief Information Security Officer

• RMiT Exposure Draft mandates FIs to designate a Chief Information Security Officer responsible
for, among others, ensuring information assets and technologies are adequately protected and
enforcing compliance with the TRMF and CRF

Security Risk Management Models 8


RMiT-Data Centres

• Given the importance of data centres to the operations of an FI, the RMiT Exposure Draft will
require FIs to ensure that its production data centres, among others, meet international
standards (such as having multiple paths for power as well as cooling systems in place).
• Minimum technical requirements must also be put in place where the FIs host its production
data centres on third-party facilities.

Security Risk Management Models 9


RMiT-Cloud Storage

• There is also greater clarity on the use of cloud services.


• Apart from for certain critical technology functions and confidential information which cannot
be hosted on a public cloud, the RMiT Exposure Draft does not prohibit the use of cloud.

Security Risk Management Models 10


RMiT-Outsourcing to Third Parties

• RMiT Exposure Draft requires comprehensive due diligence to be conducted on third-party


service providers before critical technology functions and systems can be outsourced.
• The outsourcing arrangements will also need to be recorded in service level agreements and
incorporate certain minimum requirements. For licensed banks and insurers, additional
obligations are encapsulated in the outsourcing policy document issued by BNM.

Security Risk Management Models 11


RMiT-Summary

• The issuance of the RMiT Exposure Draft reflects the growing sentiment among financial service
regulators in the region that FIs will need to bolster its cyber defenses to ensure that its systems
and customer data are afforded greater protection.
• MAS, for example, has recently issued a consultation paper on Notice on Cyber Hygiene on 6
September 2018, which seeks to prescribe certain cybersecurity practices as baseline hygiene
standards for cybersecurity.
• The RMiT Exposure Draft is a move in a similar direction. Given the scope and standards of the
requirements introduced under the RMiT Exposure Draft, FIs should immediately take the
opportunity to review existing systems, frameworks and processes.
• This includes revising any existing policies that are similar to the TRMF and CRF to ensure that it
meets the stipulated requirements.
• In addition, FIs should begin identifying appropriately qualified candidates for the various
offices and positions; given the competition for talent in this space.

Security Risk Management Models 12


MAS Technology Risk Management Guidelines (TRMG)

• In, The Monetary Authority of Singapore (MAS) had published a set of Technology Risk
Management Guidelines (TRMG) to help financial institutions address technology risks.

Security Risk Management Models 13


Introduction

• IT is important to financial institutions (FI) business strategies.


• IT systems of FIs become more complex.
• FIs are offering more variety of IT services, therefore FIs should fully understand and manage
the technology risks.
• 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.
• TRMG is not legally binding, but MAS strongly encourage FIs to consider.

Security Risk Management Models 14


Definition of Financial Institution

Security Risk Management Models 15


Applicability of the Guidelines

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

Security Risk Management Models 16


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

• Critical IT system failures can lead to reputational damage, regulatory breaches, revenue and
business losses.
• Board and SM should have oversight of technology risks and ensure IT is capable of
supporting business.

IT Policies,
Roles and
Standards and
Responsibilities
Procedures

People
IT Security
Selection
Awareness
Process

Security Risk Management Models 17


Roles and Responsibilities

• Board and SM should ensure TRM framework is established and maintained. They should be
involved in key IT decisions.
• Board and SM should ensure that controls and practices achieve security, reliability, resiliency
and recoverability.
• 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)

Security Risk Management Models 18


IT Policies, Standards and Procedures

• FIs should establish policies, standards and procedures to manage risks and safeguard
information system assets (data, systems, network device and other IT equipment).
• Policies, standards and procedures should be reviewed and updated regularly.
• Compliance process should verify that standards and procedures are enforced. Deviations
should be addressed on a timely basis by a follow-up process.

Security Risk Management Models 19


People Selection Process

• Have a screening process to carefully select staff, vendors and contractors to minimize
technology risks due to system failure, internal sabotage or fraud.
• Staff, vendors and contractors authorized to access systems should be required to protect
sensitive or confidential information.

Security Risk Management Models 20


IT Security Awareness

• 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.
• Training program conducted and updated at least annually. Applicable to new and existing staff,
contractors and vendors, accessing IT resources.
• SM to endorse training program. Content to be reviewed and updated to be relevant to
emerging and evolving technology risks.

Security Risk Management Models 21


Technology Risk Management Framework (TRMF)

• TRM framework manage risks in a systematic and consistent manner.


• It encompasses:
•Roles and responsibilities in managing technology risks.
•Identification and prioritization 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.
• Risk management practices and internal controls should be instituted to be effective.

Security Risk Management Models 22


TRMF-Information System Assets

• Assets should be adequately protected from unauthorised access, misuse, fraudulent


modification, suppression or disclosure.
• FIs should establish clear policy on assets protection. Identify criticality of assets to develop
protection plans.

Security Risk Management Models 23


TRMF-Risk Identification

• 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
• Threat may take any forms as long as it can cause harm by exploiting system vulnerabilities.
Humans are significant sources of threats.
• FIs should be vigilant in monitoring mutating and growing risks e.g. ransomware outbreaks.

Security Risk Management Models 24


TRMF-Risk Assessment

• Analyze and quantify the business and operations impact of risks identified.
• Extent of impact depends on likelihood of threat and vulnerabilities occurring and causing
harm.
• FIs should develop a threat and vulnerability matrix to assess potential impact and prioritize
risks.

Security Risk Management Models 25


TRMF-Risk Treatment

• 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.
• Risk mitigation entails a methodical approach for evaluating > prioritizing > implementing risk control,
which includes a combination of:
• technical control
• procedural control
• operational control
• functional control
• FIs should priorities 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.
• FIs should maintain their business stability (costs effectiveness concerns) while managing and
controlling risks.
• FIs should avoid implementing IT systems with unmanageable risks.
• FIs should consider taking insurance cover if applicable.

Security Risk Management Models 26


TRMG-Risk Monitoring and Reporting

• 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
• 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.
• FIs should review, evaluate, and update risk controls as IT environment changes to maintain
effectiveness.
• Review and update of risk controls should also consider changing circumstances and risk profile
of the FI.

Security Risk Management Models 27


Management of IT Outsourcing Risks (1)

• There are many forms of IT outsourcing. May be single or multiple vendors, local or abroad.
• Board and SM must exercise due diligence before entering into an agreement or contract with
outsourcing party.
• 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
• 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

Security Risk Management Models 28


Management of IT Outsourcing Risks (2)

• 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.
• 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).
• FIs should require service provider to implement the above controls as stringent as itself would.
• 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.

Security Risk Management Models 29


Management of IT Outsourcing Risks (3)

• FIs should require service provider to have DR contingency framework (defines roles and
responsibilities for documenting, maintaining and testing DR plans).
• Everyone concerned (including outsourced partners) should receive regular training in executing
DR.
• DR plan should be reviewed, updated and tested regularly, according to changing environment.
• FIs should have contingency plan for viable alternatives to resume operations if service provider
experience critical failure in a credible worst case scenario.

Security Risk Management Models 30


Management of IT Outsourcing Risks (4)
Cloud Computing

• 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.
• 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
• 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.
• FIs should have contractual power and means to promptly remove or destroy data stored with service provider on
contract termination.
• FIs should verify the service provider’s ability to recover within the stipulated RTO before outsourcing.

Security Risk Management Models 31


IT Service Management

• IT service management framework supports:


•IT systems, services, operations
•change and incident management
•stability of production environment
• Framework should include governance structure and processes and procedures for:
•change management
•software release management
•incident management
•capacity management

Security Risk Management Models 32


IT Service Management-Change Management

• Establish process to ensure production systems changes are assessed > approved > implemented >
reviewed.
• Process should apply to:
• system and security configuration changes
• patches for hardware devices
• software updates
• Risk and impact analysis should be performed before deploying changes. Consider affected:
• infrastructure, network
• upstream and downstream systems
• security implications
• software compatibility
• Changes should be tested before deploying to production. Test plans should be documented. Tests
results should be sign-off by users.
• Changes to production environment should only be approved by personnel with delegated authority.
• 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.
• FIs should ensure logs are recorded for changes made.

Security Risk Management Models 33


IT Service Management-Program Migration

• Migration involves moving codes and scripts from development to test or production
environment. Risks of malicious code injections.
• Each environment should be physically or logically separated.
• 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.
• Segregation of duties should be enforced to ensure no single individual can alone develop,
compile and move objects across environments.
• Successful changes in production should also be replicated in DR system for consistency.

Security Risk Management Models 34


IT Service Management-Incident Management (1)

• IT incident should be managed to avoid mishandling or aggravating of situation that prolong


service disruption.
• 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
• Analyzing of incidents
• Remediating of incidents
• Monitoring of incidents
• FIs may delegate to a centralized technical helpdesk for assessing and assigning severity levels
to incidents. Criteria of severity levels should be established and documented.
• Escalation and resolution procedures, and resolution timeframes should be appropriate to
respective severity level.

Security Risk Management Models 35


IT Service Management-Incident Management(2)

• Escalation and response plan should be tested on a regular basis.


• FIs should have an emergency response team made up of internal staff, with the technical and operational
skills to handle major incidents.
• 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.
• FIs should have predetermined action plan to address public relations issues, to maintain customer
confidence throughout a crisis.
• FIs should keep customers informed of any major incident and consider effectiveness of communication
(includes informing the general public).
• FIs should perform root-cause and impact analysis for major incidents and take remediation actions to
prevent recurrence.
• 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

Security Risk Management Models 36


IT Service Management-Incident Management(3)

• Analysis should cover:


• Root Cause Analysis
• when, where, why, and how the incident happened.
• How frequent the incident occurred over last 3 years.
• Lessons learnt from incident.
• 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.
• 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.
• FIs should address all incidents within corresponding resolution timeframes, and monitor all
incidents to their resolution.

Security Risk Management Models 37


IT Service Management-Problem Management

• Problem management aim to determine and eliminate root cause to prevent occurrence of
repeated problems.
• FIs should establish roles and responsibilities, and identify > classify > priorities > address
problems in a timely manner.
• FIs should define criteria to categories problems by severity level, and establish target
resolution time and escalation processes for each severity levels.
• Trend analysis of past incidents will help with problem identification.

Security Risk Management Models 38


IT Service Management-Capacity Management

• FIs should ensure indicators for systems and infrastructure such as performance, capacity, and
utilization are monitored and reviewed.
• FIs should establish monitoring processes and appropriate threshold to be able to cater
additional resources in a timely manner.

Security Risk Management Models 39


Systems Reliability, Availability and Recoverability

• This is important as critical system failures can lead to widespread and disruptive impact,
affecting reputation and confidence.
• FIs should define recovery and business resumption priorities, test and practice its contingency
procedures.

Security Risk Management Models 40


System Availability

• Important factors are:


• adequate capacity
• reliable performance
• fast response time
• scalability
• swift recovery capability
• FIs should develop built-in redundancies to reduce single point of failure. Should maintain
standby hardware, software and network components for fast recovery.
• 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.

Security Risk Management Models 41


Disaster Recovery Plan

• 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.
• FIs should review and update recovery plan and incident response procedures at least annually or when there are
operations, systems or network changes.
• 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.
• 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.
• FIs should establish a geographically separated recovery site to restore critical systems and resume business
operations when primary site fails.
• Recovery speed requirements depend on criticality and available alternatives. FIs may explore on-site redundancy
and real-time data replication to enhance recovery capability.
• 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.

Security Risk Management Models 42


Disaster Recovery Testing

• FIs should refrain from adopting impromptu and untested recovery measures during system
outage, as they carry high operational risks without validating effectiveness.
• FIs should test the effectiveness of recovery requirements and ability of staff to execute the
procedures at least annually.
• DR tests should cover various scenarios like total shutdown, primary site failure, and individual
component failure.
• FIs should conduct bilateral or multilateral recovery testing for systems or networks linked to
specific service providers.
• 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.

Security Risk Management Models 43


Data Backup Management

• FIs should develop data backup strategy for storage of critical information.
• 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 FIs should carry out periodic testing of backup media and assess if media is
adequate and effective in supporting recovery processes.
• FIs should encrypt backup media (including USB disks) containing sensitive information before
transporting to offsite storage.

Security Risk Management Models 44


Operational Infrastructure Security Management

• Is 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.
• 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.

Security Risk Management Models 45


Data Loss Prevention

• 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 unauthorized access, copy, or transmission of important and
confidential data.
• 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.
• FIs should address risks of data theft, data loss and data leakage from endpoints. Confidential information should
be stored with strong encryption.
• FIs should not use unsafe internet services to exchange confidential information, and implement measures to
detect and prevent the use of such services.
• 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.
• Confidential information stored on IT systems should be encrypted with strong access controls and principle of
“least privilege”.
• least privilege = “need-to-have” basis.
• FIs should determine the appropriate media sanitization method, depending of security requirement of data, to
prevent loss of confidential information through disposal of IT systems.

Security Risk Management Models 46


Technology Refresh Management

• FIs should maintain up-to-date inventory of software and hardware used in production and DR
environments, including relevant warranty and support contracts.
• FIs should actively replace outdated and unsupported systems, as EOS (end of service) products
cease to have security patches for vulnerabilities.
• 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.

Security Risk Management Models 47


Network and Security Configuration Management

• 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.
• FIs should conduct regular enforcement review to ensure baseline standards are applied, with
frequency of review which commensurate with the level of risks.
• FIs should apply anti-virus to servers. Update anti-virus definition files regularly and schedule
automatic scans.
• FIs should install network security devices (firewalls, IDS, IPS) at critical infrastructure juncture
to protect network perimeter. Deploy internal firewalls or similar measure to minimize security
exposure to both internal and external network. Regularly backup and review network security
rules to remain appropriate and relevant.
• FIs deploying WLAN should be aware of the risks and implement measures to secure network
from unauthorized access.

Security Risk Management Models 48


Vulnerability Assessment (VA) and Penetration Testing

• VA is the process to discover > identify > assess security vulnerabilities in a system. FIs should
conduct VA regularly.
• 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).
• FIs should establish process to remedy issues identified in VAs, and validate the success.
• FIs should conduct pen-test through simulating actual attacks to evaluate security posture of
system. Pen-test on internet-facing system at least annually.

Security Risk Management Models 49


Patch Management

• FIs should establish patch management procedures that identify > categorize > priorities
security patches, and have implementation timeframe for each category.
• FIs should test security patches rigorously before deploying to production.

Security Risk Management Models 50


Security Monitoring

• FIs should establish security monitoring systems and processes to promptly detect unauthorized
or malicious activities by external and internal parties.
• FIs should implement network surveillance and security monitoring procedures with network
security devices to be alerted of intrusions.
• FIs should implement security monitoring tools which detects changes to critical IT resources, to
identify unauthorized changes.
• FIs should perform real-time monitoring of security events for critical systems.
• FIs should regularly review security logs of systems, applications and network devices for
anomalies.
• FIs should adequately protect and retain system logs for future investigations. Retention period
should consider statutory requirements.

Security Risk Management Models 51


Data Centres Protection and Controls

• It is important for DC to be resilient and physically secured.


• Threat and Vulnerability Risk Assessment (TVRA)
• TVRA identify security threats and operational weakness in a DC to determine the level and type of protection to be
established.
• TVRA should consider various scenarios (theft, explosives, arson, unauthorized 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
• 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
• 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.

Security Risk Management Models 52


Physical Security

• FIs should limit DC access to authorized staff only (principle of least privilege).
• FIs should ensure temporary access for non-DC personnel are properly notified, approved, and
accompanied by authorized employee.
• FIs should ensure DC is physically secured and monitored, employing physical, human, and
procedural controls where appropriate (security guards, card access systems, mantraps,
bollards).
• FIs should deploy security systems and surveillance tools to monitor and record activities within
DC. Have physical security measures to prevent unauthorized access to systems, equipment
racks and tapes.

Security Risk Management Models 53


Data Centre Resiliency

• FIs should assess redundancy and fault tolerance in:


• electrical power
• air-conditioning
• fire suppression
• data communications
• FIs should monitor and regulate environment within DC such as temperature and humidity. Escalate
to management and resolve abnormalities detected in a timely manner.
• 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)
• FIs should install backup power consisting:
• uninterrupted power supplies
• battery arrays
• diesel generators

Security Risk Management Models 54


Access Control

• 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 initialization 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 authorization for legitimate purposes.

Security Risk Management Models 55


User Access Management

• FIs should only grant access on need-to-use basis and within required period. Ensure that
resource owner authorize and approve the access.
• External parties given access to critical systems should be subjected to close supervision,
monitoring, access restrictions similar to internal staff.
• FIs should ensure user access are uniquely identified and logged for audit and review purposes.
• FIs should regularly review user access privileges to verify that privilege is appropriate, and
identify dormant or wrongly provisioned accounts.
• FIs should enforce strong password controls that include:
• change of password on first logon
• minimum password length and history
• password complexity
• maximum validity period
• 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.

Security Risk Management Models 56


Privileged Access Management

• FIs should apply stringent selection criteria and thorough screening when appointing staff for
critical operations and security functions.
• These staff (system admin, security officers, programmers) are capable of severely damaging
critical systems by virtue of their privilege access.
• 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 unauthorized access

Security Risk Management Models 57


Online Financial Services

• FIs should recognize the risk of offering services via internet platform.
• 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)
• 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.

Security Risk Management Models 58


Online Systems Security

• FIs should devise security strategy to ensure confidentiality, integrity, and availability of data and systems.
• FIs should assure customers that online services are adequately protected and authenticated.
• MAS expects FIs to properly evaluate security requirements associated with internet systems and adopt well-established
international encryption standards.
• FIs should ensure information processed, stored, or transmitted are accurate, reliable and complete, by implementing
physical and logical access security, processing and transmission controls.
• 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.
• FIs should maintain high resiliency and availability, put in place measures to plan and track capacity utilization and guard
against online attacks.
• FIs should implement 2FA login and transaction-signing. These secure authentication process, protect data integrity, and
enhance customer confidence.
• For systems serving institutional investors, accredited investors or corporate entities, using alternate controls and processes
to authorize transactions, FIs should perform risk assessment to ensure security level is at least as adequate as token-based
mechanisms.
• FIs should take appropriate measures to minimize exposure to other cyber attacks such as MITM, MIT Browser, MIT
Application.
• 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.

Security Risk Management Models 59


Mobile Online Services and Payments Security

• 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).
• Mobile Payment refers to use of mobile devices to make payments, which may use various
technologies (e.g. NFC).
• 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.
• 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.
• FIs should educate customers on security measures to protect their own mobile devices from
malware.

Security Risk Management Models 60


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

• Payment cards allows physical purchase, online purchase (and over mail-order or over
telephone) and ATM cash withdrawals.
• 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).
• Payment card frauds include:
•counterfeit
•lost or stolen
•card-not-received (CNR)
•card-not-present (CNP)

Security Risk Management Models 61


Payment Card Fraud

• 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.
• 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.
• 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.
• FIs should ensure security controls on payment card systems and network.
• FIs should only activate new payment cards upon obtaining customer’s instruction.
• FIs should implement dynamic OTP for CNP transactions via internet to reduce risk.
• FIs should promptly notify cardholders when withdrawals or charges exceeding customer-defined threshold is made. Alert
should include transaction source and amount.
• FIs should implement robust fraud detection systems with behavioral 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.
• FIs should investigate transactions that deviates significantly from cardholder’s usual usage patterns and obtain
cardholder’s authorization before completing transactions.

Security Risk Management Models 62


ATMs and Payment Kiosk Security

• ATMs and payment kiosks (e.g. SAM and AXS) are targets of card skimming attacks.
• 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.
• Verify adequate physical security are implemented in third party payment kiosks which accept
and process FI’s payment cards.

Security Risk Management Models 63


IT Audit

• FIs need to develop effective internal control systems to manage technology risks.
• IT audit provides Board and SM independent and objective assessment of the effectiveness of
controls to manage technology risks.
• FIs should establish organizational structure and reporting lines for IT audit in a way that
preserves the independence and objectivity.
• Audit Planning and Remediation Tracking
• FIs should ensure IT audit scope is comprehensive and includes all critical systems.
• IT audit plan comprising auditable IT areas for the coming year should be developed, and approved by
the FI’s Audit Committee.
• FIs should establish audit cycle and determine the frequency of IT audit that commensurate with
criticality and risk of IT system or process.
• 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.

Security Risk Management Models 64


TRMG – Next Steps?

https://sbr.com.sg/financial-services/news/mas-tightens-
cybersecurity-rules-fis?page=1
Security Risk Management Models 65
https://sbr.com.sg/financial-services/in-focus/singapore-plays-catch-sophisticated-cyber-attacks
ISO 31000 - Enterprise Risk Management

• The ISO standards use a framework of 7Rs and 4Ts to develop risk frameworks, which are:
•Recognition or identification of risks
•Ranking or evaluation of risks
•Responding to significant risks
•Tolerate
•Treat
•Transfer
•Terminate
•Resourcing controls
•Reaction planning
•Reporting and monitoring risk performance
•Reviewing the risk management framework

Further reading : Digital Financial Services and Risk Management Handbook - IFC

Security Risk Management Models 66


Thank You
[email protected]
Twitter:@svanank

Security Risk Management Models 67


References
• https://sbr.com.sg/financial-services/in-focus/singapore-plays-catch-sophisticated-cyber-attacks
• https://sbr.com.sg/financial-services/news/mas-tightens-cybersecurity-rules-fis?page=1
• https://simpledu.wordpress.com/2017/03/30/mas-technology-risk-management-guidelines-
trmg/
• https://www.pwc.com/sg/en/financial-services/assets/techriskmanagement201307.pdf
• https://www.lexisnexis.com/en-us/products/entity-insight/technology-risk.page
• https://nehemiahsecurity.com/blog/cybersecurity-technology-risk/
• https://www.conventuslaw.com/report/bank-negara-malaysia-issues-exposure-draft-of-risk/
• https://www.ifc.org/wps/wcm/connect/06c7896a-47e1-40af-8213-
af7f2672e68b/Digital+Financial+Services+and+Risk+Management+Handbook.pdf?MOD=AJPERES

Security Risk Management Models 68

You might also like