Non-Functional Requirements -
Compliance
This document contains NFRs categorized under Compliance. Each NFR is numbered
sequentially.
NFR No. Requirement
NFR-COM-001 Create/modify/deletion of entitlements must be recorded in the audit
logs. Each activity of Create/modify/deletion of the user must be
captured and stored in the backend/audit log
NFR-COM-002 Entitlement review of termination and revocation of the accounts
must be captured and data must be stored in the audit log
NFR-COM-003 Data protection: Each time a record gets deleted, system or
application should capture the deleted record in the audit log.
Additionally, if any data that must be deleted is unable to be deleted,
the log should contain the details of what was not deleted and the
reason why not
NFR-COM-004 Data Collection when the user sign up or modify the profile
information- Data should only be stored in the audit log that is
needed. Specifically applications should avoid collecting sensitive
information such as health records, race, political affiliation, caste,
religion etc. Application must be configured to ensure that the
controls can be implemented such that administrative support roles
cannot view information belonging to individuals of specific
level/band/locations etc.
NFR-COM-005 The application must ensure that Any combination of PII (Personally
Identifiable Information) that identifies an individual’ PII must be
protected against unauthorized access. Customer name or contact
information in combination with social security number, national ID
or tax number, driver's license, passport or account number is an
example of confidential PII. Masking replaces enough characters in
any given piece of information so that the entire text is not guessable,
but provides only enough information so that it allows a legitimate
user to confirm it is the correct data (e.g., account number). Certain
requirements such as DSS may dictate the specific masking
requirements. If masking is not feasible due to business requirements,
appropriate controls must be in place to prevent inadvertent or
unauthorized disclosure/access of the data
NFR-COM-006 The application must generate its own keys for cryptographic
functions. If the application utilizes technology components such as
cryptographic libraries provided by a programming language or other
applications specifically intended for key generation (i.e. OpenSSL),
the application is considered to be generating its own keys and they
should be stored in the audit log. The application team would be
responsible for key lifecycle management as described in the Key
Management Standard(KMS).
NFR-COM-007 The application must password Based Encryption (PBE): Passkey
used for Password Based Encryption (PBE) must have the following
length/complexity: Information classified as Confidential, or higher
relating to a single customer sent to that customer (including
eStatements): minimum 8 alphanumeric characters including at least
one upper and one lower case letter. In cases where character case is
not supported, minimum length of 9 alphanumeric characters. All
other instances of Information classified as Confidential, or higher
including sending the information relating to the multiple
users/customer/individuals, complexity of the password will be
defined.
NFR-COM-008 Key Backup and Archiving. If the application is subject to supervisory
or data retention requirements, there must be a process in place for
backup and archiving of the data (including passkeys, basic info of the
user/customer) used to encrypt the data which is being retained.
Recovery must be enforced, such that all encrypted messages or data
can be decrypted and recorded in the log for audit evidences
NFR-COM-009 The application must prevent unauthorized access and modifications
to the audit logs to ensure that logs cannot be overwritten or modified
by the system users whose activity they track. And also ensure
controls in place to audit log data is backed-up or archived prior to
being rolled over. Audit log configuration also should alert the
administrator when the size of the log exceeds
NFR-COM-010 The application must prevent storing of confidential and above data
that persistently stored on a system in the DMZ. Persistently stored
means storage beyond the session lifetime.
NFR-COM-011 Secure Cookies: Application uses cookies containing Confidential or
higher information; the cookies must be marked as secured so that the
cookies are sent only over encrypted channels. And ensure the cookies
encrypted using an approved algorithm. Also, make sure cookies non-
persistent (expire at the end of the session)
NFR-COM-012 Web Contents Cache: Application must prevent
Confidential/Restricted data from being cached on user's local disk by
setting browser directives. Sensitive web pages containing
Confidential/Restricted data must not be cached on user's local disk. It
could be accomplished by implementing HTTP response header with
the certain directives.
NFR-COM-013 The application must sensitive Data Protection: Does the application
encrypt sensitive data such as PII , authentication data and business
sensitive information during transit
NFR-COM-014 The application must sensitive Data Protection at Rest. Does the
application encrypt sensitive data such as PII, authentication data and
business sensitive information during storage?
NFR-COM-015 The application must secure Cookies: If the application uses cookies
containing Confidential or higher information, following must be
implemented a) the cookies marked secured so that the cookies are
sent only over encrypted channels b) the cookies encrypted using a
approved algorithm. c) the cookies non-persistent (expire at the end
of the session)
NFR-COM-016 Web Contents Cache: The application must prevent
Confidential/Restricted data from being cached on user's local disk by
setting browser directives
NFR-COM-017 Audit/Logging of SMS: The application must capture SMS messages in
audit logs
NFR-COM-018 Sensitive Data Protection: The application must encrypt sensitive data
such as PII, authentication data and business sensitive information
during transit
NFR-COM-019 Terms and Conditions: The application must ensure require the
customer to accept the Terms & Conditions at the first login to the
application. This ensures compliance with PII regulations requiring
Company group to inform the user of why Company is
accessing/collecting personal data and why Company is using it.
NFR-COM-020 Push Notification Controls: The application must introduce/modify
push notification like Apple, Firebase or some other third party cloud
based event mechanism. Acceptable Criteria: - TLS appropriate
version in place per Company standards. Content signing used to
validate the origination of the push notification. Authentication and
authorization mechanism in place between the client app, push
notification service and application server. The credentials are
managed independently by a dedicated group, not development. Data
classified confidential PII or higher must have payload encryption in
addition to the transmission level encryption.
NFR-COM-021 The application must external Cloud Provider Approval: If the
application uses an External Cloud Provider and involving information
classified as Confidential or higher information, the solution has to be
approved by ISROC in accordance with the Cloud Computing Security
Assessment Process (CCSAP) - prior to going live, or annually
thereafter
NFR-COM-022 Information Classification: The application's information must be
classified in accordance with all sections of the Information
Classification Standard. E.g. Information Owners (as defined in the IT
Common Glossary) must classify the structured information they own
using the IS classification levels described in the Information
Classification Standard (ICS).All Company workers must classify
unstructured information under their control using the IS
classification levels described in the ICS. Information obtained from
Service Providers must be classified in accordance with the ICS. This
includes information accessed online requiring authentication and not
hosted or owned by Company . (Required controls for handling and
protecting information based on information classification are
detailed in the Data Protection Standard.)Information Owners for
structured data in applications and Company workers who manage
unstructured data must evaluate the information’s overall sensitivity
level based on the data elements that are collected, processed, stored,
transmitted, accessed, or disposed. Sensitivity levels are determined
by the potential impact to the firm or its affiliates if the confidentiality,
integrity or availability (CIA) of the information were ever
compromised. The four possible information sensitivity classification
levels for information at Company are described in the ICS.
Information Owners and Company workers managing information
must determine whether PII is present in the data, and if it is, must
classify the sensitivity of that PII using the three (3) possible
classification levels for PII in the ICS.(Further requirements for the
identification of PII are defined in the Company group Privacy and
Bank Customer Confidentiality Policy.)After evaluating the data as
described in ICS Sections 3.2 and 3.3, Information Owners and/or
Company Workers must record the classification. Where possible,
Sensitivity Level and PII Category must be recorded as separate fields.
Where this is not possible, in order to ensure that the appropriate
level of data protection controls is applied, the information should
receive a single classification based on the most sensitive data present
(i.e. the high watermark), as per the hierarchy in the ICS.
NFR-COM-023 TPISA. If the application is hosted by a Third Party or using a Third
Party's service, the Third Party Risk Assessment Process must be
completed in accordance with the Third Party Management (TPM)
Policy.
