資訊安全中心

Business Continuity Strategy

---

This section of the Information Technology Business Continuity Plan describes the strategy devised to maintain business continuity in the event of a facilities disruption. This strategy would be invoked should the NFC Touch Information Technology primary facility somehow be damaged or inaccessible.

Business Function Recovery Priorities

The strategy is to recover critical Information Technology business functions at the alternate site location. This can be possible if an offsite strategy has been put into effect by Office Services and Disaster Recovery/IT Teams to provide the recovery service. Information Systems will recover IT functions based on the critical departmental business functions and defined strategies.

Relocation Strategy and Alternate Business Site

In the event of a disaster or disruption to the office facilities, the strategy is to recover operations by relocating to an alternate business site. The short-term strategies (for disruptions lasting two weeks or less), which have been selected, include:

• Primary Location: Room 3, 8/F, Ho Lik Centre, 66A Sha Tsui Road, Tsuen Wan, N.T., Hong Kong
• Alternative Location: RM11-13, 9/F, Block A Wat Tat Ind Ctr, 8-10 Wah Sing Street, Kwai Chung

For all locations, if a long-term disruption occurs (i.e. major building destruction, etc.); the above strategies will be used in the short-term (less than two weeks). The long-term strategies will be to acquire/lease and equip new office space in another building in the same metropolitan area.

Recovery Plan Phases

The activities necessary to recover from a NFC Touch facilities disaster or disruption will be divided into four phases. These phases will follow each other sequentially in time.

• 1. Disaster Occurrence - This phase begins with the occurrence of the disaster event and continues until a decision is made to activate the recovery plans. The major activities that take place in this phase includes: emergency response measures, notification of management, damage assessment activities, and declaration of the disaster.
• 2. Plan Activation - In this phase, the Business Continuity Plans are put into effect. This phase continues until the alternate facility is occupied, critical business functions reestablished, and computer system service restored to NFC Touch’s Departments. The major activities in this phase include: notification and assembly of the recovery teams, implementation of interim procedures, and relocation to the secondary facility/backup site, and re-establishment of data communications.
• 3. Alternate Site Operations - This phase begins after secondary facility operations are established and continues until the primary facility is restored. The primary recovery activities during this phase are backlog reduction and alternate facility processing procedures.
• 4. Transition to Primary Site - This phase consists of any and all activities necessary to make the transition back to a primary facility location.

Vital Records Backup

All vital records for Information Technology that would be affected by a facilities disruption are maintained and controlled by either Information Technology or Disaster Recovery/IT. Some of these files are periodically backed up and stored at an offsite location as part of normal Information Technology operations.
When Information Technology requires on-site file rooms, scanning, and organization offsite storage locations, best practices advise using one near-by Records Warehouse and another secure site for vital records and data back-up. All vital documents are typically located in files within the office complex and the most current back-up copies are in a secure off-site storage facility.

問題？

如果您對本政策或程序有疑問或意見，或想取得副本以供參考。請透過以下電子郵件地址與我們聯絡：[email protected]

Data Loss Prevention (DLP) Policy

---

This policy is a guide in identifying and gaining an understanding of the components of NFC Touch Ltd that make up its information security system and thereby enable NFC Touch to manage risk to systems, assets, data, and capabilities.

Policy

Data Loss Prevention (DLP) is a set of technologies and business policies to make sure end-users do not send sensitive or confidential data outside the organization without proper authorization. DLP enforces remediation with alerts, encryption, and other protective actions to prevent end users from accidentally or maliciously sharing data that could put the organization at risk. Sensitive information might include financial records, customer data, credit card data, or other protected information. The most common method that this data is leaked is via email.

Policy Information

Beginning June 1, 2020, all email that contains sensitive information will be automatically blocked. The sender will receive an Outlook message when an email is sent that contains sensitive information. Faculty and staff can still manually encrypt any email.

Best Pratices

• Do not forward email you receive that contains sensitive information. If it is required to do so, redact the sensitive information before replying.
• Seek alternate means of transmitting the sensitive data. (secure web applications, etc.)

Continuous Improvement

The content of this document subject to regular review based on input from NFC Touch Technical Services team.

問題？

如果您對本政策或程序有疑問或意見，或想取得副本以供參考。請透過以下電子郵件地址與我們聯絡：[email protected]

Data Privacy Annex

---

IN CONSIDERATION OF the continued engagement of NFC Touch, NFC Touch would agree to the following additional terms and conditions:

1. NFC Touch shall, at all times, comply with the obligation on data users set out in Data Protection Law in relation to all Personal Data that is processed by it in the course of performing its obligations under this Agreement.

2. NFC Touch shall only use the Personal Data as reasonably required in connection with the performance of its obligations under the provision of smart business card application (the “Services”).

3. NFC Touch shall comply with the reasonable procedures or processes notified to NFC Touch by our client with respect to Personal Data from time to time.

4. NFC Touch shall not disclose the Personal Data to any third parties other than:

• (i) to employees to whom the disclosure is necessary for the provision of the Services, provided it is made subject to obligations of confidentiality no less onerous than those imposed upon NFC Touch and is consistent with any reasonable procedures specified by the Company from time to time; or
• (ii) to the extent required by any Regulator, provided NFC Touch gives written notice to the Company of any such disclosure promptly after it becomes aware of that requirement.

5. NFC Touch shall implement and maintain all reasonable technical and organisational measures to maintain security, prevent unauthorised or unlawful access to or processing of Personal Data and accidental loss or destruction of, or damage to, Personal Data. NFC Touch shall give our client written notice as soon as NFC Touch becomes aware of any breach of its data protection obligations under the agreement or of any enforcement proceeding against it under the Data Protection Law.

6. Without prejudice to any other provision of this Agreement, the Company may at reasonable intervals (or sooner if the Company has reason to suspect breaches of the terms of this supplemental agreement), request a detailed description of the technical and organisational methods employed by NFC Touch and its subcontractors for the use, handling and security of Personal Data. Within thirty (30) calendar days after the request, NFC Touch shall deliver a written report to the Company in sufficient detail that the Company can reasonably determine whether or not any applicable Personal Data is being or has been used and handled in compliance with the Data Protection Law.

7. If the subject of any Personal Data makes a written request for access to any relevant Personal Data, NFC Touch shall immediately notify the Company (if the request has been directed to NFC Touch) and, subject to any other instructions by the Company, shall provide details of the Personal Data held by it in relation to that person within twenty (20) calendar days after its receipt of the request for that Personal Data.

問題？

如果您對本政策或程序有疑問或意見，或想取得副本以供參考。請透過以下電子郵件地址與我們聯絡：[email protected]

Risk Management Procedure

---

This procedure is to define the process of information security risk management, including risk identification, risk analysis, risk evaluation, and risk treatment. It also includes the criteria of risk assessment and risk acceptance for the company the evaluate the information security risk.

Risk Assessment

The Risk Assessment should be performed using the “Information Security Risk Assessment Form”.

Risk Identification

Identify Assets, Systems, or Areas

Identify vulnerabilities that may have in each assets, systems, or areas.

Identify risk describe how the vulnerability creates a risk in terms of confidentiality, integrity, and/or availability elements that may results in a compromise of the IS system and the data it handles. The events happening in the past, the present, and the future should be considered.

Risk Analysis

Determine the Likelihood of Occurrence - The likelihood is an estimate of the frequency of such a risk.

Risk Treatment

There are four basic strategies for managing risk: mitigation, transference, acceptance, and avoidance. A risk management plan must be planned that reduces the risk to an acceptance level. For each risk management plan, the steps for achieving the strategy must also be determined. The corresponding risk management strategy shall be listed in “Risk Management Plan”.

Risk Mitigation involves fixing the flaw or providing some type of compensatory control to reduce the likelihood or impact associated with the flaw.

Risk Transference is the process of allowing another party to accept the risk. Risk is transferred from the individual to a pool of insurance holders, including the insurance company. Note that this does not decrease the likelihood or fix any flaws, but it does reduce the overall impact (primarily financial).

Risk Acceptance is the practice of simply allowing the system to operate with a known risk. If the risk level meets the risk acceptance criteria, there is no need for implementing additional controls and the risk can be retained. Many low risks are simply accepted. Risks that have an extremely high cost to mitigate are also often accepted. Ensure that this strategy is in writing and accepted by the management making the decision.

Risk Re-Assessment

Shall review the information security risk in yearly basis or when there is incident occurred or the need of changes.

問題？

如果您對本政策或程序有疑問或意見，或想取得副本以供參考。請透過以下電子郵件地址與我們聯絡：[email protected]

Application Security

---

Application development team shall include security planning and implement the appropriate security measures and controls for system under development according to the systems' security requirements.

Application Development & Maintenance

Documentation of applications shall be properly maintained and restricted on a need-to- know basis. For outsourced projects, all information made available to the vendors shall be protected by the non-disclosure agreements and/or the clause we stated in the tender documents.

Formal testing and review on the security controls of system shall be performed prior to production.

Integrity of an application shall be maintained with appropriate security controls such as version control mechanism and separation of environments for development, system testing, acceptance testing, and production. All source codes for production shall be controlled by source code control system such as Microsoft Visual SourceSafe.

Application development & supporting staff shall not access production information unless having gained the consent of system owner and/or respective IT Manager or above. Proper logging on production information access should be enforced.

The design of an application should align with the secure network zoning practice during the system implementation. Application servers/web servers and database servers for intranet access and internet access should be in separate network zones. Each zone shall be under firewall protection.

All source codes of application shall be developed in a high-quality manner and compliant to industrial security standards (e.g. NIST, CERT and SANS). Application development team and vendors shall provide sufficient evidence that there is no critical vulnerability identified by reviewing the source code before production launch using secure code analyzer (e.g. Fortify or Ounce).

All vulnerabilities should be fixed before the rollout of applications. In case of provided vulnerability fix (such as filter/clean servlets) cannot be verified by code analyzer, application team should understand all risks and provide sufficient justifications/workarounds for acceptance of certain risks before the system launch with consent of system owner and respective IT Manager.

Unless approved by Information Security Manager, all system should only display the first alphabetical letter(s) and the first 4 digits of HKID number, and other numbers would then be masked with asterisk on graphical user interface (GUI) and hardcopy printout.

Configuration Management & Control

Change control procedures for any program/system changes shall be documented and any program/system changes shall be documented with consent of respective IT Manager.

Careful consideration shall be taken and Information Security Manager shall be consulted for changes that will affect existing security mechanisms.

Any change on computer equipment and system software shall be performed under control and with record.

問題？

如果您對本政策或程序有疑問或意見，或想取得副本以供參考。請透過以下電子郵件地址與我們聯絡：[email protected]

Information Security Event and Weakness Management

---

This procedure is to provide guidelines to deal with a security incident that occurs, in form of intervention to contain, negate or minimise the impact of the security incident and to ensure a quick, effective, and orderly response to security incidents and disaster recovery.

Process Flow

Refer to the “Information Security Event and Weakness Management Flow” for the sequence and interaction of event and weakness handling.

Information security events and weaknesses should be reported to Helpdesk using one of the following methods:

• Emailing [email protected]
• Calling Helpdesk on 3611-0980

Anyone, including NFC Touch staff or subcontractors, who uses the division’s information (hardcopy or electronic) and/or has access to division’s IT systems is responsible for reporting, even if the event or weakness identified is not within his / her area of direct responsibility. Staffs and subcontractors are responsible for reporting any information security event or weakness notified to them by a third party.

Information security event shall be assessed and decided if it is to be classified as an information security incident for vulnerability managed by NFC Touch system;

• The security event shall be classified as a security incident if the event caused the accidental or malicious destruction, loss, alteration, unauthorized disclosure of, or access to information;
• Record the decision on the “NFC Touch Security Event / Weakness Report”.

Incident investigation

The Information Security Team shall identify the sensitivity level of the security incident.

When there is evidence showing that an incident has occurred, case owner, system owner, and NFC Touch service owner should perform an initial analysis to determine the scope of the incident, and access the impact on the division’s information system, information resources and operations.

Investigation of the incident will include the collection and recording of evidence:

• Systems or areas affected;
• Information affected;
• Amount and sensitivity of information involved;
• Potential loss or damage.

Evidence of investigation must be well protected and retained for a minimum of 6 months after the end of the investigation.

Forensic evidence

As part of the investigation process a forensic examination of equipment may be required for evidential purposes. If a forensic examination needs to take place the following must be adhered to:

• Evidence must be stored in the secure place;
• Evidence must be retained for a minimum of 6 months after the end of the investigation.

問題？

如果您對本政策或程序有疑問或意見，或想取得副本以供參考。請透過以下電子郵件地址與我們聯絡：[email protected]

Data Retention and Destruction Policy Procedure

---

This policy exists to set out the principles for the safe retention and destruction of data stored in inserted.

Scope

The policy covers all data stored within our SaaS platform, including all personally identifiable information (PII). It refers to the collection, transformation, accessing, updating, transferring and destruction of digital data specifically as they occur in this instance.

Responsibility

This policy applies to all insert company officers, employees, partners, contractors and services providers that may have access to the NFC Applications. It is the responsibility of all the above parties to familiarize themselves with this Policy and ensure their compliance.

Retention Period by Data Type

Customer data used for the support of smart business card application purposes.

• Internal communication including email and other correspondence.
• Uniquely identifiable customer data.
• Interactions with customers including complaints and other items that are not significant.
• Customer’s policies and procedures.

Retention Period: Not longer than 3 years after the end of contract.

問題？

如果您對本政策或程序有疑問或意見，或想取得副本以供參考。請透過以下電子郵件地址與我們聯絡：[email protected]

Patch Management Procedure

---

Patch management is the process for identifying, acquiring, installing, and verifying patches for products and systems. Patches correct security and functionality problems in operating systems, 3rd party software and device firmware. From a security perspective, patches are built to mitigate software vulnerabilities; applying patches to eliminate these vulnerabilities significantly reduces the opportunities for exploitation. Patches can also add new features to software and firmware, including security capabilities.

Acquisition

Patches/hot fixes must be acquired through trusted industry source (e.g. product vendor website, 3rd party security advisory website, Microsoft security bulletin). The initial acquisition must be downloaded to the testing or development environment only. This cycle will be performed quarterly.

Prioritization

Risk-based approach should be adopted to perform assessment for new security vulnerabilities, patches and hot fixes. The assessment should be based on the risk of vulnerabilities exploitation and the potential negative impacts on the confidentiality, integrity and availability of the assets. In general, NFC Touch would adopt the risk rating provided by vendors from official channels (e.g. Critical/Important/Moderate/Low/Not Rated from Microsoft, High/Medium/Low by Oracle). By default, patches with rating High/Important (or equivalent) or above would be scheduled for patching execution. For those rated as Medium (or equivalent) or below are recommended to be patched but not necessary.

Zero day Vulnerabilities

In case of emergency scenarios that we are advised to patch zero day vulnerabilities, NFC Touch will take immediate action to apply patches or schedule firmware upgrades after risk evaluation. The regular patching cycle is not applicable in this kind of scenarios.

Testing

In some cases updates may break the functionality of application systems, therefore:

• Patches/hot fixes must be tested on testing or development environment before deploying into the production environment.
• Patches/hot fixes must pass the testing and be approved for deployment in the production environment.
• Technology Owner and managed service providers are accountable to ensure the patches/hot fixes are tested properly and have no negative impacts to the production environment.
• If negative impacts on systems or applications are identified during the testing, Technology Owners, managed service providers are responsible for mitigating the security vulnerabilities. Deviation request must be submitted if high severity patches cannot be applied.
• For Office PC patching, patches/hot fixes would be deployed to the machines in UAT environment first with 3 weeks testing period, followed by testing among pre-defined pilot user groups. One week testing period would be provided to the pilot groups to test and validate before full scale deployment in production environment. Pilot signoff would be assumed if there is no adverse comment received from pilot groups within the testing period.

Deployment

For application systems, Technology Owner has the responsibility to notify Service Owner before applying the patches to UAT environment. One month test period will be given to the tester(s) to perform application regression testing. No compatibility issues of application systems would be assumed if there is no adverse comment raised during the test period. Implementation Staff will schedule patching activities in production environment one week in advance. Server downtime and reboot should be communicated to Service Owner accordingly.

Patching Cycle

The patching cycle for patches/hot fixes are dependent upon the criticality of the application systems:

• System Critical application system and Office PC Non-critical application system
• System criticality Critical Ordinary
• Patch criticality Critical/High Medium/Low Critical/High Medium/Low
• Day Within 90 days from the completion of the previous patching cycle Recommended to patch but not necessary Within 180 days from the completion of the previous patching cycle Recommended to patch but not necessary

Verification

Systems that have been patched must be validated to success of deployment.
The verification of deployment status should be reported using an automated tool or manual effort if automated tool is not available for specific platforms.

問題？

如果您對本政策或程序有疑問或意見，或想取得副本以供參考。請透過以下電子郵件地址與我們聯絡：[email protected]

Service Agreement

---

Purpose of this is to provide clear reference to service ownership, accountability, roles and/or responsibilities.

Service Scope

The following services are covered by our service:

• Manned telephone support
• Monitored email support
• Remote assistance using Remote Desktop and a Virtual Private Network where available
• Planned or Emergency Onsite assistance
• Monthly system health check

Service Management

Effective support of in-scope services is a result of maintaining consistent service levels. The following sections provide relevant details on service availability, monitoring of in-scope services and related components.

Service Availability

Coverage parameters specific to the service(s) covered in this Agreement are as follows:

• Telephone support : 9:00 A.M. to 5:00 P.M. Monday – Friday
  - Calls received out of office hours will be forwarded to a mobile phone and best efforts will be made to answer / action the call, however there will be a backup answer phone service
• Email support: Monitored 9:00 A.M. to 5:00 P.M. Monday – Friday
  - Emails received outside of office hours will be collected, however no action can be guaranteed until the next working day
• Onsite assistance guaranteed within 72 hours during the business week

Service Requests

In support of services outlined, we will respond to service related incidents and/or requests submitted within the following time frames:

• 0-8 hours (during business hours) for issues classified as High priority.
• Within 48 hours for issues classified as Medium priority.
• Within 5 working days for issues classified as Low priority.

Remote assistance will be provided in-line with the above timescales dependent on the priority of the support request.

問題？

如果您對本政策或程序有疑問或意見，或想取得副本以供參考。請透過以下電子郵件地址與我們聯絡：[email protected]

Data Security

---

This document aims to illustrate relevant concepts and best practices related to different aspects of information security for all staff to observe and follow.

Overall Data Confidentiality

Information that may compromise the security of any system shall not be disclosed to users, or any other third parties, unless authorized an IT Manager or above on a need-to-know basis.

All information classified as CONFIDENTIAL shall be encrypted. Confidential data shall be encrypted with password during transmission to requestor over networks. Those passwords should not be passed via email or any written format.

Staff shall comply with Information Security Policy when storing, transmitting, processing, or destroying classified information.

Personal Data (Privacy) Ordinance (Cap. 486) shall be observed when handling personal data. For more information of the Ordinance, please refer to website http://www.pcpd.org.hk.

Production data shall not be replicated or used in non-production environments. Any use of customer data in non-production environments requires explicit and must comply with all legal and regulatory requirements for scrubbing of sensitive data elements.

Production Data Backup

Backup and recovery procedures shall be well documented and properly implemented. Restoration test should be done weekly and the test result should be recorded and kept before the backup media are disposed of.

Backups shall be carried out at regular intervals according to the following backup/retention cycles:

• Backup Cycle: Daily - Minimal Retention Period: 3 weeks
• Backup Cycle: Weekly - Minimal Retention Period: 9 weeks
• Backup Cycle: Monthly - Minimal Retention Period: 13 Months
• Backup Cycle: Yearly - Minimal Retention Period: 7 years

Backup activities shall be reviewed yearly.

Complete copies of backups of production systems should be stored at off-site computer center. Backup media should also be protected against unauthorized access, misuse or corruption during transportation.

問題？

如果您對本政策或程序有疑問或意見，或想取得副本以供參考。請透過以下電子郵件地址與我們聯絡：[email protected]

Nonconformity, Corrective Action and Preventive Action

---

Use efficient improving, corrective and preventive action to ensure continues improvement in IT security.

Policy and Management of continues improvement

NFC Touch should increase the effectiveness and efficiency of Information security Management to achieve continues improvement. Each department should seek improvement continuously in each process.

Corrective action

Relative corrective action should be taken to correct non-conformity.

Recognize the effect of non-conformity on ISMS:

• i. Exceeding the limit set by our company for complying to applicable legal and other requirements if necessary
• ii. Failure in achieving the objective targets set by the management plan
• iii. Nonconformity indicated during internal audit

After the completion of each corrective action, IT Manager should follow up and inspect the effectiveness of this action. Responsible department head should sign on " corrective / preventive action report ".

Preventive action

Potential non-conformity should be recognize and take preventive action to eliminate the cause.

IT Manager can recognize the nonconformity base on following record:

• i. Past internal and external audit record and management review record
• ii. Corrective, preventive and improve action implementation record etc

When any potential nonconformity is discovered, IT Manager gather all related department to analyze and review the cause, also determine the preventive action and responsible department. Responsible department should implement preventive action and IT Manager review the effectiveness of this action.

Control and record of improve, corrective and preventive action

All meeting minutes and record about improve, corrective and preventive action should be filed. Department head should report the progression of improving, corrective and preventive action to IT Manager.

Meeting minutes and record of critical improving, corrective and preventive action will become the reference of next management review meeting

問題？

如果您對本政策或程序有疑問或意見，或想取得副本以供參考。請透過以下電子郵件地址與我們聯絡：[email protected]