IT Security Requirements for a new IT System

IT Security Requirements for a new IT System

Ownership and Criticality of the System:

Business Owner (Name, Department and Designation);

IT System Manager (Name, Department and Designation);

Project Manager;

Project Name;

Cost Charge Code;

Confidentiality, Integrity and Availability rating of the System (Define Worst Case Impact if each of the components is affected).

Availability rating should determine the RTO and RPO of the system.

Describe the scope of change introduced by the project.

Describe the purpose of the system and its functions.

Describe the user base of the system.

Provide inter-system (between different systems) connectivity diagram.

Provide intra-system (within the system) connectivity diagram.

Indicate the Datacenter (DC) where each system is hosted.

Data-In-Motion Encryption – All data transfer from component to component should be using secure protocols which provides encryption of the data being transferred (SFTP, FTPS, Secure-JDBC, SSL, SSH, etc)

Data-At-Rest Encryption:

Option 1 – Application Server level encryption of data before storing into Database (Application administrators have full access to data)

Option 2 – Database level encryption of data (Application administrators and DBAs have full access to data).

Option 3 – Disk/SAN level encryption of data (Application administrators, DBAs and OS administrators have full access to data).

Password Controls:

Password should enforce the inclusion of Uppercase, Lowercase, Number and Symbol.  Enforce the non-usage of past 10 passwords.  Enforce password expiry for every 90 days.  Passwords must use a minimum of 15 characters.

[Guidance: Use Passphrases instead of a word.  Example: IHave1cat&ILoveIt! ]

Two-Factor Authentication should be used for access to application/systems over the Internet.  The second factor being SMS OTP or Hardware Token OTP.

Transaction Signing (OTP generated from Hardware Token based on input value related to the transaction or input value sent through SMS) should be used for authorizing financial transactions and for changing of critical customer data, over the internet.

Session Inactivity:

(i) [Optional] The session should be locked after a pre-defined period of inactivity;

(ii) The session should be logged-out after a pre-defined period of inactivity;

Confidential data at Endpoint Devices:

Confidential data should not be stored into disk storage in Endpoint devices, without a strong Need-To-Have.  If there is a strong Need-To-Have, the data should be stored into Encrypted Containers and the Integrity of the Container should be verified before the data is re-used by the application.

Cache at Endpoint Devices:

Cache used in endpoint devices should be cleared when the application logs out.

Critical Processes at Trusted System:

Input Validation, Output Encoding, Authentication, Authorization, Session Identifier Creation, Cryptographic Functions to protect secrets from Application User and Logging Controls should be implemented at the Trusted System – at the Server side; and not at the User Endpoint.

Authentication should be required for accessing each page and resource at the server side, unless public usage is intended. 

Access Control:

Please provide Access Roles-Permissions Matrix (including Business and IT).  Please indicate which Roles are classified as Privileged Roles.

Security Logging:

Process for recording, protection, retention, ~review of security logs (login/logout, change to access rights, security configurations, etc) should be established.

Activity Logging:

Process for recording, protection, retention and ~review of activity logs should be established.

Secure Coding Practices:

Use OWASP Secure Coding Practice Quick Reference Checklist during code development and review.

Integrity of Golden Source Data:

Any data that is received by the application to be used as a golden source should be integrity verified by the Business Owner.

Network and Application Penetration Testing:

Internal Network and Application Gray Box Penetration Testing should be performed for Internet Facing Systems and Critical Internal Systems before Go-Live.

Platform Vulnerability Assessment:

Platform (OS, DB, and Device) vulnerability assessment should be performed before System Go-Live.

Anti-Malware Protection:

Anti-Malware Solutions should be installed on all Wintel Platforms supporting the System.

Support Documentations:

Documentations should be created to ensure that there is adequate information to support ongoing operations, problem resolution and future maintenance of the system.

Project Level IT Security Requirements (Non-Functional Requirements) –

IT Security Requirements for a new IT System

Business Owner vs IT Manager (Application Management Responsibilities)

The roles of Application Business Owner and Application IT Manager are often not clearly defined within an Organizational setup or not well understood.  The definition of these two roles are quintessential to ensure that responsibilities and accountabilities are appropriately placed for the Management of an IT Application.

Application Business Owner Accountabilities

  • Determine Business Criticality, Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
  • Data Ownership – Identify, Classify and Protect Data.
  • Application Access Control Ownership – Ensure that access to the application, on both the Business and IT side, are as per the Need-To-Have Principle.
  • Responsible for the Application’s Information Security Governance and Control and Regulatory Compliance.

Application IT Manager Responsibilities

  • Implement IT controls to Protect Data.
  • Ensure that access to the application , on the IT side, are as per Need-To-Have Principle.
  • Support the Application Business Owner by providing oversight of IT implementation and processes.


Business Owner vs IT Manager (Application Management Responsibilities)

IT System Controls (High Level)

IT System Controls

  1. Identification of Business Owner and IT Manager
  1. Assessment of Business Criticality of the System
  1. MAS TRM checklistshould be completed by the Service Provider team  for Compliance with MAS Technology Risk Management Guidelines.  This should be answered from the perspective of the Service Provider team and is intended to measure the Service Provider’s own internal controls.

  1. MAS Outsourcing Technology Questionnaireshould be completed by the Outsourcer/Business Owner together with the Service Provider.

  1. Data Flow Diagramshowing component-to-component data flow and interfaces with other IT Systems should be created and Data Transfer Protocols should be identified.  Secure protocols should be used for data transfer.
  1. Confidential Data should be encryptedin-storage (Database or SAN level encryption) and in-transit (both external and internal connections).
  1. Functional/Non-Functional Specifications Documentshould be created.
  1. IT Risk Assessmentshould be initiated and completed. 
  1. Multiple-Factor Authentication for access over the internet and for Privileged Accessshould be implemented.
  1. Penetration Testing(Network level and Application level White box testing) should be performed for Internet Facing Components. 
  1.  Datacenter and Operations Center Inspection.
  1. Datacenter TVRA(Threat, Vulnerability and Risk Assessment)
  1. PDPA Compliance– Signoff from the Data Protection Officer once the compliance is achieved.
  1. Cross Border Data Transfer/Access Regulatory Compliance– Sign-off from Compliance team after their clearance.
  1. Source Code Security Reviews for Sensitive Modules– particularly modules dealing with Authentication, Transactions, and Customer Confidential Data.
  1. Controls surrounding Application Business Roles and Access– should be implemented by the Business Owner.
  1. Controls surrounding Application IT Roles and Access– should be implemented by the IT Application Manager. 
  1. Controls surrounding Platform IT Roles and Access– should be implemented by the IT Infrastructure Manager. 
  1. Application Password Controls – Comply with Password Guidelines.
  1. Transaction Signing.
  1. IT Architecture Standards should be met.
  1. Data Loss Prevention Solutions– Endpoint controls should be implemented by Service Provider.
  1. Source Code Ownership/Escrow Arrangements – Should be discussed and agreed by the Business.
  1. MAS Reporting for Relevant Incidents – Establish processes to meet the regulatory requirement to report to MAS within 1 hour for Security Incidents (if the system contains Customer PII) / System Malfunction (if the application is classified as MAS Critical).
  1. IT Control Enforcement through Legal Contract Clauses– A Legal Contract should be established, which enforces applicable IT Controls, SLAs, Incident Reporting Timelines, etc.


IT System Controls (High Level)

Application Security

Below are the main Application Security controls that should be implemented:

Access Authentication 

Access to the Application should use Secure Authentication Methods which meets or exceeds the Company’s authentication standards.  The session should be ended and user logged-out after a stipulated period of inactivity.  A stipulated number of consecutive failed login attempts should result in lockout of the account, which should only be unlocked by an administrator.  Privileged Access to the Application should ideally be using a higher level of security than normal access (example: Multi-factor authentication, more stringent password criteria, etc). The Business Application Owner should define the following:

  • Threshold of idle time before logout of user
  • Number of consecutive failed logins before lockout
  • Privileged Access vs Normal Access within the Application

Main Points: (Passwords, Inactivity Account Log-Out, Failed Login Attempt Account Lockout, Privileged Access Authentication)

Access Authorization 

Access Matrix defining the different Roles and their Privileges within the Application should be documented.  The process through which access to the Application can be Requested/Modified/Deleted and the associated Approvals required should be defined and documented.  The process should also cater for immediate removal of Leaver/Transferee accounts.   Audit trails should be created for all access changes using the Company’s Standard Access Request Management platform.

Main Points: (Access Matrix, Access Management Process, Audit Trail Maintenance)

Access Recertification 

Normal and Privileged Accounts within the Application should be recertified periodically (Normal accounts – at least once a year; Privileged Accounts – at least once every quarter).    Evidence of recertification and follow-up action taken to correct the access provisioning, should be retained.  The process for carrying out recertification, responsible parties, timeframe of execution, follow-up actions, and evidence retention mechanism should be defined and documented.

Main Points: (Access Recertification Process, Evidence Retention)

Activity Logging 

Activity Logging should be enabled by the application.  The logs should capture the following:

  • Timestamp of occurrence of the activity
  • User ID carrying out the activity
  • Normal activity/transaction details (example: financial transactions, user login/logoff, configuration changes to the application, application exceptions, etc)
  • Sensitive activity/transaction details (example: financial transactions beyond a threshold, adding/modifying/deleting customer/user accounts, sensitive configuration changes to the application, user account lockout, critical application exceptions, etc)

Logs should not capture passwords, sensitive Personally Identifiable Information (PII) or Payment Card Information. The Business Application Owner should define the activity/transactions to be captured by the Application.

Activity Log Retention 

Activity Logs should be available readily for review by the responsible party.  Activity logs should be retained in backup for a defined-lifetime. (as-is the current practice within the Company).

Privileged Account Identification

Privileged access gives an elevated level of access in order to perform a task on operating systems, databases, network devices and applications. These include accesses that:

  • Have the ability to create other accounts, delete existing accounts or change the privileges of accounts; and/or
  • Have the ability to modify system security and critical application configurations (examples: Password Requirements, Transaction limits, Portfolio limit, Watch List Monitoring Parameters, etc);  and/or
  • Bypass system security controls (example: delete logs, turn off security services, modify data in the backend application database directly).

Privileged Activity Review 

Sensitive activity/transactions should be reviewed periodically by a Responsible Party.  The process for carrying out review of sensitive activity/transactions, parties responsible for performing the review, timeframe for review, follow-up actions, format of storage of evidence of review and evidence retention mechanisms should be defined and documented.

Main Points: (Sensitive Activity Review Process, Evidence Retention)

Data Security

Data Integrity and Confidentiality should be protected in transit, storage and in disposal.  Secure electronic data transfer/access mechanisms (based on SSL/TLS) should be used.

Transaction Signing

FIs should implement two-factor authentication at login for all types of online financial systems and transaction-signing for authorizing transactions from customers.

Location based Access Control

Software-as-a-Service used by the Company over the Internet should restrict access to the Company’s staff by only allowing connection from the Company’s office locations (based on IP address).

Application Security